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One of the most difficult tasks facing computer scientists is that of 
designing systems and making sure that they perform their intended functions 
correctly. As computer systems heave grown im size end complexity, the 
problems of system design and verification heve become increasingly acute. 
Formal specifications, which are precise descriptions of a system's function, 
provide a basis for understanding system operation as well as for proving 
correctness. 
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CHAPTER 1:. INTRODUCTION | 


1.1. System design and specification = i> 


The fields of computer hardware and software both deal with the 
same fundamental goal building systems to ‘perform designated f ‘unctions, _ A 
hardware 4 system is constructed from physical components, . while. a software 
system is realized by writing programs in a » language. implemented on seme 
computer. As both hardware ang software systems have Brown in size and 
capability over the years, thetr _ structure : and operation. have grown 
tremendously in ‘complexity. This has made the task of designing . Systems 
increasingly difficult, especially so for large, high-performance Systems, . It is 
important that both aeem. designers and users have . confidence. that their 
systems perform their functions as intended. System testing, debugging, and 
modification constitute a significant fraction of the time and exrene involved 
in designing systems, The issues of making ‘certain. that a system being 
designed will operate correctly are thus “of particular ‘Amportance ‘to both 


hardware and software system ‘designers, 
{ 


Verifying | the logical correctness | of system designs has been 
accompli sted in ‘practice mostly by “seat of the Pants" techniques. _ The 
drawbacks of such an informal approach are Clear: one cap. be intuitively 
certain that a SS design is correct, pat Looe ds far. from a guarantee of 
correctness. There are numerous , "horror stories" about . systems that had to be 
redesigned or scrapped. because their designs had serious sonceptual , errors that 


went undetected in the veriticnton process. Such errors indicate a lack of 


understanding on the part of the designers as to exactly what functions the 
systems are supposed te pértenes,: tis ibrane to- hive’ sound understanding of 
the way a system operates, and in order to be sure that it behaves correctly, 
it is necessary to make use of precise; deanriptians. sof ia Usyetem's,“ lagicel 
function. It is for just this reason ae saad ‘@acipline of formal 
specifications has arisen, Specifications are “deecriptions of the behavior 


Leyghbs te ad 


desired of @ system, and a system is shown to be correct by verifying that it 
: 


Satisfies its ‘specifications, ‘Le. operates as it is intended ie ‘dehave, There are 


Peres : 
ip, sy af 


two significant benefits “that may ‘be realized by using formal specifications. ; 
First, it becomes possible to develop formal verification methodologies, which 
makes it feasible to prove that systems are correctiy dasigned to perform their 
intended “tasks. Second, formal descriptions  sielae a a ‘model. ‘through “which 


complex ‘systems can be Better understood. "Thus, the he task of system design 
may be ‘facilitated through ‘the audy of ‘formal oem specification and 


ey 


verification techniques. 


Formal specification be sree til cannot ke used. Jeindly without 
considering the nature of ‘the syeems being described. For latge, complex 
“systems, the specifications may become hed complicated as to make correctness 
proofs intractably difficult. iiaetinde: this. eles can ig alleviated by 
treating only those aystems that satisfy “nice” propertiea, wy ‘insisting oa 
appropriate system consivaints that must be satistied, one can ‘identify classes 
of ‘systemis that ‘ave more ‘orderly ‘and structured design with 1 no mee secrifice 
in functional capability. Through judicious use of this concept ‘of ssructured 


system design, the system designer can te sacaves of working = seems 
that can be more sanity understood, déecrivea and verified. | 


ey ae 


Formal specifications have been the ceiver of much jasearch activity 
‘Within the software field [Rustin, 1972; Liskov and Berzins, 1976]. In 
‘addition, an entire discipline known as sifuctured’ prograiiming has arisen to 
study ideas of structured system design and their ramifications on the 
programming process (Dijkstra, 1972; Wortman, 1977}. * However, there has 
been relatively little research ‘in corresponding areas of the hardware field. 
One might explain this difference by saying that there is a much greater 
concentration of theoreticians specializing “in software ‘than hardware, but 


there is a more crucial underlying reason, Design costs 8 for hardware systems 


assembly. Once a machine ia ‘into production, the design process is ended; all 
further costs lie in replication and- maintenance.” For these. economic reasons, 
the physical construction ef systems: has: been. the deminant factor in hardware 
development, With software, on the other: hand, desigi-costs have always 
predominated; since: everything is: ‘Tealized: on! paper, . Moresever,; software 
systems are designed for. specilic eppeationnl cid the prabiems to. -dbe handled 
are changed; thén the programs must ‘often. de Yewritten ‘or redesigned. 
Hardware systems are general-purpose in. that-fora changes tn application it is 
the program: and not the machine that is modified.:::Software is thus far more 
transient than -hardware, which makes design costs even’ diore ‘mportant for 
software, It is therefore no: wonder that ‘the -Andtdatives: for: studying design 
and specification msethodolegies have been strongest ia the software field. 

The rapid developments in semiconductor ‘technology “over the past 
few years are beginning to a alter ‘the ‘ economic i: balance. in hardware 


development. Integrated circuit ‘chips can be mass-produced at extremely low 


cost. Construction costs for hard ware aystems are _ Sxopping.. dramatically as 
new fabrication techniques are coming into practice... Since. Gosign. costs. are 
remaining essentially the same, they are becoming more and more Significant 
in relation to synen development. This means thet system, design techniques 
and approaches will soon be on the cufting edge of hapdware technology. For 
large and complex systems, whose logical functions are especially difficult to 
sensrchent and work with, the approaches to sytem design are even more 
crucial. It is therefore important to open up a thorough investigation of 
formal specification and structured system design, ‘me 


oologies for hardware — 
systems. And since much of _the initiative . in. this, area has come from 
software research, it is naturel to Jook for ways to, Apply new technologies 
used in software design to the hardware Beld,— 


A perticular cleas of systems Called packet. comanucation .,ystems, 
which are described im the next section, has been chesen as the: domain for 
the research presented here. Packet :chmmusication systems ate based.on a ‘sat 
of structural properties which provide . fos: the ‘matiding of = lerge, 
high-performance systems and which. -alseo support the develapment of a 
theoretical. framework for formal. specification and. verification,::.In this thesis, 
‘we shah develop techziques for formal specification of the: behavior of packst 
communication systems. We shell. also take a look.at how the formal 
specifications may he applied: towards verifying the legitsi correctaiess of these 
systems. Becouse these has deen a0. little formel study: nf: methoddlogies for 
hardware system design, specification and verification, the research here may 
be considered as the first step in . new direction. 3 


a 


1.2. Packet communication architecture and its background 


Packet communication. architecture.is a.set of principles according to- 
which systems may be designed and structured... The systems satisfying these 
principles are collectively. known as pecket :commupiegtion _systems;;. for 
brevity, they shall also be. called pecket systems, -As inizoduced. by Dennis. in 
(Dennis, 1975b], packet systems . are. essentially interconnections of 
independently functioning units that interact only by sending each other 
packets of information. The information contained ia a: packet may have 


arbitrarily complex structure. 


In this. research; we Rave taken a particular point of view, 
regarding packet systems as being’ physicaliy composed from * hardware units. 
Some of the important -eoncepts underlyitig packet commutication architecture 
are particularly advantageous when applied to-the “design and implementation 
of hardware systems, It is equally valid,..theugh,. te implement packet . 
systems in software, There are no existing techniques for formally specifying 
or verifying packet systems viewed from. the.-software standpoint; so our 
work here ‘may also. be seen as an advance in. the study of. software 


specification as well. 


There are two particular notions from the study of structured 
programming that are directly supported by the principles of packet 
communication architecture: modularity ‘and hierarchy. ‘Tikese ndtiors play a 
large role in the suitability of applying formal ‘specification techniques to 


packet systems. 
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composing them from smaller units called modules. The basic idea is that the 
use of a module 1s separated: fromthe intétadl detatls of ‘its implementation. 
In this way, a module cam be developed dat changed without ‘affecting other 
‘Modules; The eomeeptd-of ‘modularity ‘ fty “are’-dishuineet ti” mere detail ‘in 
{Myers, 1975 YourSen, 1076; Dennis, t9?&b}, “An‘example of a mechanism 
for supporting ‘modularity ce: software’ ‘systems ‘is ‘the udtion of data 
abstraction [Liskov and ‘Zilles, 1974}. “A désirable design’ ‘goal for thodular 
systems is that: individual ‘modules: be ‘as delftcontaiined “#nit independént as 
ti ‘among different 


possible. This goal can be realized by making’ Kite 3 sc 
modules as. simply..structured as possible, thagughs;cleam, well-defined 
interfaces. . Although the. advantages of modulanly strestnzed aystems are cleer, 
problem. We shall not.iavestigate this groblem here... 


the issues of des 


The wetion of Mererchy rélates*to “how systentéidiy be viewed and 
described, A ‘Aletarchieeliy structeted system" ts one ‘that’ tidy ‘be’ sttatifiea 
into’ different levels “of conceptual’ detail. “Bach “ level “makis use of 


mechanisms whose internal éeGdilé ‘aré“hitien wwal’ ih ‘lower levels. “Each 
mechanism within the system is used at higher, more abstract Yevets than 
where it is defined. Ja, this way,..Jow-level..deteil ig deolated .g0 that it will 
not interfere with. higher-level conceptual vinews..of the guetem. The. basic 
Principles. apd concepts of hierarchy .in systems have beam, presented by Pennas 
[Parnas, 1974; Parnay, 1876)... 


The properties of modularity and ‘hierarchy make systems in general 
easier to understand and work with. ” Each module ‘in a hierarchical ‘and 
modular system has a set of “neighbor” modulés with which it éamimunicates: 
The behavior of a given module depends: ‘on the uveitinns oy which it 
interacts with its neighbors, but it {8 completely independent of the internal 
characteristics of the éther modules in the system. ‘Consequently, the designer 
of a module need not woity’ ‘about “what goes fnstde’ any ‘other modules; the 
only relevant concerns are the “internal “€onstruction. and the interface 
conventions ‘for the particular module being “Pestgied. ‘In this way, design 
taformation ia paititionad dlokg the beuiidaiial of “the modules, insulating the 
system désigner ‘from irrelevant detail. This insulation is further enhanced in 
hierarcKical éystem stfuétures, Each level of abstraction in the hierarchy is 
isolated from the other levels. ‘The designer of a médule has to know the 
external behavioral characteristics of the subfiodules from which the module. 
is composed, but the intérmal strictures of ticsubmodules should be “‘totaily 
irrelevant to the design: of the given modile. : “thus, systems ‘that are both 
modular and hierarchical have two dimensions ‘along which design details are 
partitioned. When the’ structure of’ ‘a System’ prevents. certain design 
information from affecting areas it does not ‘concern, the system design is 
simpler to’ ‘understand... Conceptual ‘sintplitity:s~an~ important design goal 
whenever: system: ‘specification and: vecitieetiow: ae: to' 6 daken into account.- - 


Although the concepts of modularity and hierarchy have been given 
far less theoretical’ aitention’ in relation ‘to hardware than software, they are 
almost universally regarded as fundamental ‘to "good hardware design practice. 


Hardware systems have for a long time been ‘built’ Up “from moduies such as 


-~1Z- 
adders, clocks amd shift registers, and nowe there is qm oven gosster variety of 
off-the-shelf component chips to we of modules ‘At & higher level of 
abstraction, a _. typical microcomputer is composed of s microprocessor, some 
RAM storage, VO drivers end interface elements. | , aah of hese, components. 
can be treated as a modula, and these modules cam themaslves: be. decomposed. 
For example, the processor has as submodules an afer, Various registers, 
gating logic, an instruction decoder and cther compenenty these submodules 
can in turn be further Geeompeset. This example shows how digital. system 
design exhibits hierarchical and modular: progertian, _ In. general, these 
properties are reid by intelligent, system design, Ws they are éifficult 10 
achieve when designing large computing. systems, _Festures. such. as. virtual 
memory, multi-user environments, parallel gaan. and the sharing. of 
data among diffesemt processes are difficult to. realise, they are ysually 
implemented in psactice. either by, simulating them in seftware or by. adding. 
new components as afterthoughts to a basic Vou, Neymann machine, _ khe. 
interactions among these. added. components are anything, but Modular in. 
nature, which is one of the ‘Teasons why large Computing. systems ate. 30 
difficult to build. Packet _Sommunication 


aye EPyse 
provides: direct support for hierarchy and modularity. — 


Packet. syatems are doth senduler ‘and, hiesarchieal. in.structure. The 
moduies in @ packet eratem: we shmply: the: independantiy: epexrating: units. tivat 
comprise it. Packet systems: can easily ve Structured so. that their modules 
correspond te the conceptual. units in the designer's View of the system. 
Further, ine principles of packet communication arhiterrure aliow the 
modules that form. a packet system to be viewed. individually as systems. thas. 
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may themselves be decomposed into interconnected, component modules, This 
hierarchical property of packet systems ecovites: some of ‘the major conceptual 
foundations of the approach to specification and verification that will be 
developed. By “making hierarchy and modularity ” explicit, packet 
communication architecture not only. “facilitates | “formal npscit ication and 


verification, ‘but in addition serves ‘to encourage good system design practice, 


One of the most parent design goals ‘tor packet systems is that 
the modules within a system operate as independently as possible. In support 
of this goal, it is required that modules eominenicue with each other by 
passing packets asynchronously. This ‘principle eliminates the need for a 
centralized control facility to ‘ coordinate the action of a the modules, which 
greatly — simplifies system structure. "Moreover, it provides for ‘concurrent 
operation of the modules, leading to enhanced ‘syste: performance. A module, 
while awaiting response from other modules in order t to perform oe tasks, 
can busy itself with other tasks for which | rhe required ‘responses have 
already arrived. An operation may proceed as soon as s the information it needs 
is received, as opposed to what happens with conventional. architectures, in 
which operations cannot be performed until ‘they are explicitly initiated by 
the sequential control. It is this distinction that Provides for “conuiseney' and 


thus allows packet systems to “make more effective use “of the available 


resources than do conventional large systems, | 
The iecouacits example given above exhibits a number of 
hierarchical levels of abstraction. It may be noted that the interfaces between 


modules at different levels of the hierarchy have completely different 
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characteristics, At the top loved one deals beklaca transmission of applications 
datai within the microprocessor, microinstructions are passed; ane. at a a) 
lower level, it is basic logical signals ‘that are passed, and ated, om digital 
systems as they are currently designed, interface protocols depend on the Speed 
at which the various modules process control ana, Nada signals. , Phils 


Ara? 


dependence limits the degree of modularity that can be ) achieved in existing 


systems, since a module's interface with its ‘outside world is not free of 


internal speed and timing ¢ considerations. 


Esckst systems are not subject to such limitations; one of “their 
important properties is that the timing characteristics of an individual module 
in a packet system do not atiect the ‘operation of any other module. A 
module in a packet system can be replaced with another unit that performs 
the same task orsers: of magnitude fener o slower _— the original module, 
and this change will not alter the logical functioning of the one: Packet" 
systems are _— Speed independent, ae removes from the oe the 
burden of having to take into sccouat: the speed rah timing properties of 
| system components in order to assure Jogical correctness. ‘Speed independence 
enhances the Aegres of modularity in a system and thus provides an. additional 
eléifient of structuring in systems, which further asin ic chcal design and 
verification. It “ sg noted that a syste must operate asynchronously in 
grder to achieve the goal of speed independence. Packet Ree lpnari: since they 
are speed independent, can accommodate a uniform protocol for communication 
of packets among their component modules. This® uniformity of interface 
provides the basis for the method of ‘system specification “hat will be 
described here. 
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‘The’ idea of building ‘systems by connecting independent modules 


under an asynchronous and speed-independent discipline is not new. An early 


- exposition ‘was’ “given by Muller ‘(Maller, 1963]. “There was a major research 


effort several years later directed towards realizing systems ‘that ‘were “to be 


i 


‘physically ‘ constructed | ’ from hardware dnlts”” called macromodules 


- [Ornstein, 1967]. . Patil has izivestigated logical ‘dexigns for modules with 


which asynchronous systems may be ‘baile (Dennis and. Patil, 1971), ana more 
recently he has been: working with applyiiig programmable logic arrays to “this 
task [Patil, 1975}: All of these designs © ‘aiffer from “packet Gominunication 


‘architecture in that ‘control signals and Mata values are passed through the 
_ systems separately, traVeling on two distinct sets of communication pathways. 


“In packet’ systems, the ‘potions of control and ‘data are Unified, ‘liminating the 


need: for ‘separate pathways. This is yet another. “Fespect in “which the 
principles of packet communication architecture serve ‘to. simplify system 


structure, 


-’'$ince packet systems operate concurrently, a significant area of 


‘application for packet™ communication ‘architecture ‘ties in ‘realizing computer 
 “systeias that provide direct support ‘for parallel : programming. If different 


‘parts Of a program ‘cai be executed in payaltel, ‘then it is advantageous to run 


the program on a machine fot which the “hardware can overlap their 


execution. In this Way, one can optimize Tunning speed and utilization of 


- resources’ such: as* memory, processing elements ‘and ‘peripheral devices. “The 


study of data flow computation has precisely this goal ‘in mind. ‘Data flow is 
the representation of programs “in such a “way ‘as to ‘make “the data 


dependencies and ‘iniWerent ‘parallelism ‘explicit. Given. any two ‘operations 0; 
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and O02 in a data flow program, it should be immpedigtely, apparent from the 
program structure whether (O, should ve. performed before Q,, whether 0, 
needs results of O2 in order to be performed, or. whether. 0, amd QO, are | 
independent (can be done in parallel). Reta flow programming has deen 
treated extensively ia the Literature; for doth. exposition and references, see 
[Dennis, 1975a Weng, 1975]. Substantial effort. has gone into studying 
designs for machines that can directly and efficiently. execute data flow 
Programs [Rumbaugh, 1975; Dennis, 1974; Dennis, 1977; Arvind, 1975; 
| Plas, 1976]. : On such a machine, there is uo sequencing .of instructions; an 
instruction tay be executed any time after its operqnds pecame available. 
This is essentially the same ‘Principle es the one underlying, the operation. of 
modules withia a packet system; in fect, the concapta. af packet systems have 
been directly influenced by the research in developing atchitactures | to 
implement data fiow. 


The conceptual compatibility between the ideas of data flow and 
packet communication architecture yields a natural connection between them. 
In a packet system, the activity that takes place within a module is initiated 
by the arrival of the sppropriate data. packats. There. ig no explicit SOGUORGINE 
_ of operations in data flow programs, and it should be. practical to implement 
shen on systems that do not require ordered. sequences of instructions as their 
programs. This is one. of the motivating factors behind the conception of 
packet communication architecture. Most of. its concepts - far from new or 
original, but it is the combination that makes it Paitadle for. Fealizing., data 
flow CAR teHOD, in hardware. Conversely, data, flew is 4 natural way to 


represent programs that will ‘Tun on processors ‘designed. according to..the 


ey 


‘principles ‘of ‘packet communication “architecture. < * Thus there is a 
commonality betweeti ‘data flow and packet systems thet arises because they 


share similar: goals:and principies. a Te ae 


‘There is one more property of packet ees that should be noted 
here. The behavior of a packet system, or of any of 1 its modules) is 
observable in terms of the packets it snds ‘out in response sto th the packets it 
receives. In general, gach systems are nondeterminate, which means that 
given the packets received by a module, ‘thete: may be. ‘several “distinct but 
equally valid’ responses to the input, “Wondeterminacy is one ‘of ‘the factors 
that make the behavior of packet systems “aifficult to understand and 
formalize. - This will have a definite bein: on the “approach taken here 


towards specification and verification. 


ites 
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This concludes the overview. of | the basic , ideas, of Packet 
communication architecture, The principal ‘Teason yey, packet . systems. were 
chosen for this research is that their. desige. is Structured . in’ a way that 
supports tier specification and ver icaen. The Li section presents an 
overview of some of the major concepts and techniques that have been 


developed for formal specification of ‘computer ‘Programs | and a sygtoms. 
1.3. Formal specifications 


Much of the tesearch concerned with: formally describing the 
activity within computer systems has dealt Rubies Programming language 
specifications. There are essentially three basic ‘approaches “ describing the 


behavior specified by a piece of program ‘text - axiomatic, denotational and 


ee ae 


operational. Each, approach may be applied te Verifying. the correctness. of 
program text | as welt as serving asa pure descriptive, vehicle. _ 


Axiomatic specifications capture thes afttect.-cf exetuting a programm ; 
by compere _bropertivs of _ system, state before and after execution. The 
paradigm “if assertion A is true before Program text P is. executed, then 
assertion B is true after P is executed” describes the meaning of program text 
P. Special rules of snterense are set he to describe the, meanings of various 
porbinalions of ‘program texts in terms of their. components’. ‘meanings; Shese 
rules incorporate. the basic oan properties of, constructs such 4s, iteration 
and conditionals. This approach became known, throygh, the work of Floyd 
[Floya, 1967] and Hoare [Hoare, 1969] in which it.was. used to prove 
correctness of simple flowchart-like programs that manipulated integers. . The 
assertions they used related values of program Micceremteae: There has been a 
sudstantial amount of more recent research ‘a axiomatic aoc eens 
Dijkstra (Dijkstra, 1976] hes ‘built up an entire methodology of programming 
around the ideas of axiomatic “specification. Owicki and Gries [owieki, 1976] 
extended Hoare's techniques to parallel programs; their menckins made use of 
auxiliary © “state variables to keep track of interprocess. cooydination, Greif 
(Greif, 1975] tock a ‘different approach to ‘parallel programs, using : ‘partial 


time-ordering on events to express coordination propertigs.:. 


penorarional cpewrea aoe the effect ~ a program by 
viewing the “objects they model as abstract mathematical entities. This 
approach. provides a ema ‘mathematical description. of the computational 


notions being. treated. An carly denotational “approach to specifications for 
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programming languages was the application of a mathematical formalism 
known es lambda calculus ‘towards’ deictibing the semantics of Algol 60: 
programs (Landin, 1965]. The test known work in dexidtational specifications 
has: followed from the research of Séott and” Stiachey [Scott and 
Strachey, 1971]. | Matheniatiéal results fréin lattice ‘theory ‘are used in the 
construction of complex domains over which programs “are represented as 
functions., Programs. are proved. equivalent..by showing: that their functions 
coincide. A tutorial presentation of. the. ScottrStrachey approach is given in: 
(Tennent, 1976]. . . py sine (Sa eet 


Operational’ specifications deal ‘with the changing states within 
computer systems ‘as computations are performed.” This iS done by means of a 
state-transition modet in which a state ‘Teprexents information present in “the 
system at & ‘given moment in time. “The “abtion ofa ‘ pfograin is captured by 
the sequence of’ transitions of the model. “Thé ‘geqiierice of states the model 
passes throvgh as a program is executed defities ‘the “action of an interpreter 
for the program. The idea“of using such ‘an iité?préte? to define the meaning 
of progréias in some anguage originated with McCarthy [McCarthy, 1962]. A 
well-known approach t0 operational spécifications is the Vienna Definition 
Language (VDL) described in { Wegner, 1s720), which ses ‘an interpreter that 
manipulates ° tree-structuréd system states, Dehhis' Common Base Language 
(Dennis, 1971] is similar, dealing with “note ‘general airétted’ graphs in place 
of trees, Another approach to” operatiotal” spetifidatione is due to Parnas 
(Parnes, 1972). - This: approach distinguishes two ‘Rinds “of operations: those 
that yield state information, and ‘those that™alter thé state of the system. 


' Parnas applied his approach to operations on abstract data in programming 
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languages; this was extended to the. domain of systems in. [Rokinson, 1975]. 
Verification is achieved within ah operational framewerk by. : prowling that the 
behavior of the interpreter in question is. equivelent to: the behaviog af one 
‘aie is known to perform the desired function. The ideas. underlying 
verification by interpreter. equivalence were developed by © Milner 
(Milner, 1971] and are also presented in. [Weguer, 19728). 

as software specification, thers has. been a swbwtantial amount of study of 
computer hardware description languages (CHDL’s). The approaches ‘taken 
towards hardware specification have been slmost eptirely operational. The 
iahgiade APL, before it was ever implemented as, a programming language, 
was used as a hardware description language. to. specify the gparation of 
IBM/360 computers [Falkoff, 1964]. Another CHDL, called ISP, was develeped 
by Bell and Newell [Bell and Newell, 1971] to describe the operation of a 
large number of different. computers. Both of these CHDL's describe | their 
target systems at the instruction set level, treating. machine words.as a basic 
data type with operations for byte extraction and, bitwise. arithmetic. and 
logical functions, On the other hand, the language PMS, which. was also 
developed by Bell and Newell [Bell and Newel, 1971], describes the structure 


of computer systems in- terms of their. cam: at. precassers, memories, 


controllers and I/O devices, This is an example of a CHDL describing systems 
from a higher-level conceptual point of view. BDL [Dietmeyer, 1974].is an 
example of a lower-level CHDL that defines the behavior of elements such. as 
multipliers by specifying them as, interconnections of basic logic gates, 


Most of the CHDL's have been developed with two particular goals 
in mind: automated system design, and system testing by means of 
simulation. However, the microprogram. certification project at IBM hae 
developed an approach to hardware syétem ‘specification that is directed 
towards formal verification of system desigh (Birman, 1974]. For both the 
instruction execution level and the microprogram level, a VDL-style interpreter 
is used to ‘supply formal specifications. ’ "PReése two interpreters are then 
proved equivalent in exactly the same way that correctness is proved in 
operational specifications for. programming ‘languages as described: above. The 
proof techniques for -this. approach are. additionally described in 
[Leeman, 1975; Leeman, 1977]}.’ Rumbaugh takes a‘ ‘similar approach to the © 
IBM group in proving the ‘correctness of a data flow processor 
(Rumbaugh, 1975}.. He shows ‘that an interpreter: for his machine is © 


equivalent. to one that models the operations in a data flow language. 
1.4. The approach to be presented 


The research in specifications that has been reviewed here cannot be . 
directly applied to the task of formally describing and verifying packet 
systems. The principal reason for. this is that conventional. techniques are not 
equipped to handle the asynchronous. operation of ..packet systems. . The 
concurrency in packet systems makes it dafficult to verify their. correctness: 
in order to establish some property of a. packet system, it must be shown true 
for all possible sequencings of packet transmissions and receptions within the 
system. Most. existing techniques. for formal . spegifications. do not. lend 


themselves to this kind of task. Moreover, the notion of sequencing of 


“ae = 
actions, which bed fundamental to nearly a Bai approaches that have been 


taken towards formal specifications is not present in the context Of packet 


ayateite: 


There is a descriptive formalism, Petri nets, that has been developad 
Specifically. for specifying asynchroagus: Rehavias withizt systems,’ “Petri: mets 
(Peterson, 1977] ave . directed...gzapas. in: which marleera. called: tokens” pass 
along the arcs and. through. ther vertiees to: madel the ecoursemce: of various 
events. Although they have yeqeived . much: attengion im this -pegavd 
[Patil, 1970; Hack, 1976], they cannot be dizently applied: tor verifying packet 
systems. Petri nets conwey only contrel,iaformation fer use: in: coordinating 
concurrent activities; the. natuxe af. these.activitieg is ‘left. uninterpreted: In 
particular, they do not. treat data: values that ape: nagsed: within packet 
systems. Also,,.although.. many mathematios] -aregerties: have teen. establisived 
for Petri nets, mo. methodology: has: deen: develnget: fer. appiying : them: ‘vo 
system verification. Most of their cadena applications nave been in 
connection with simulating sivuiiionecs * ballaview rather ‘than "proving 
Properties of systems.. Far. these. reasons, ,Petrt: nets de not seem. to meet the 
goals of specification and verification. of packet systems, 


Within a packest system; the ‘shdddles reeetve “anti process’ ‘friput 
packets, generate - new packets for output: ‘dnd’ “send them out, all 
asynchronously and im pagall#h, The Kind-éf approach that ‘seems most suited 
to specifying: this kind.:ef -behavior is basically operational ‘in “ature: “The 
state of a packet system describes wich’ putkets have’ been passed ‘between 
which modules (and ‘niug-also convey any: coéréination- isifosmation’ relevait: to 
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. the correct operation of the system). . However,.<unlike conventional 
operational models, the transitions. between states nead to be geverned: not by 
an externally. supplied sequence of instruptjons.te be processed by the system, 
but rather by the presence or absence:-of: packets as needed “for processing. 
This means that an. operational mode] for a packet system must take into 
account the many possible sequences Of. execution, that. could: arise from the 
flow of packets, : 


Describing: the internal operation “of ‘packet systems is not sufficient 
‘by itself for Verification purpoves.” There “must also be a method for 
7 specifying the logical- function a system is expected to perform. This function 
concerns the system’s input/output beliavior as seen ‘by the outsiae world in 
terms: of packets ‘received and’ sent out. or‘the three ‘kinds ot approaches to 
specifications ‘as disclissed’ in’ the previous gection, “e aenotational aporoachh 
“geems best suited for our ‘needs becausé it Gan be easily tailored to describe 
sequences of packets that have been ‘passed Vetween various modules. Because 
‘ef this flexibility, a-denotational approach will also interface nicely with the 
nu “we shall be working with 
two Kinds of specifications for packet” sjitediss ~ Gpacatiaual specifications to 
_ describe the internal opexation, and. denotational spécifieationsy to describe their 
behavior in relation to.the: outside world: Vesifsoutton: of corréctness for a 
_packet...system will -be:-demonstrated by proving thst: these two -sets of 
specifications for. the system agree with each other. = 


' A’ recent research effort is specifically directed towards formally 


describing the structure and behavior of packet ‘communication systems. The 
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descriptions ave expressed in a formalism called ADL (grchitecture pchittectare Description 
Language), which is introduced ia fLeang, 2977} There afd two ways in 
which & systema may be Gesurfeed i ADG: ‘strneturally and* behiviorally. A 
structural deseription chureeterises: how the iynim 1s formed! as an 
interconnection of -modaius, A dehavievaldesesiption is ax operational 
reception, processing and transmission of individual packets. ‘The notation 
the underlying semantics are also. Daced, on the principles of date flow. Ag a 
first approach to placing packet systems on a formal. foundation, ADL. is beth 
helpful and illuminating. _ However,, the Speer SK soecifying the. interpal 
operation of a packet system. hes not been developed. within the ADL 

framework. This idea, which has act been. studied previously, is. crucial for 
* vediby tig saa seabvertaess Ot Sedtaond aig: sesecinsd ual nadia Gali: 
The severest . this concept is the most significant cogtribution of our 
research. The denctationel approgch jo be used in our, teestment for 
specifying the function of systems terns cit to be. more convenient to, wee 
than the operational approsch foun 12. ADE. 


describes. the, basio. prepertinn of packet syetems:inmore Getatl. Fhe notion of 
correctness 1s defined, emt a fermetism stor. describing the ‘stracturel 
composition of packet systems is also presented. Cheput 3 presents the 
denotational part of the packet system  spscifications The. behavior of a 
packet system or module is formally defined as, a relation between the pockets 
‘it receives as input and the corresponding pockets seat out in response. 
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Chapter 4 motivates and defines the central concepts of the research, giving 
an operational characterization of the actions that take place within a pecket 
system. Chapter 5 shows how the specification model developed in the two 
preceding chapters may be applied to the task of verifying ‘Correctness of 
packet systems. . Three sample systems are proven correct, and a theorem is 
presented to show how the model may be simplified in certain came. 


2.1. Overview 


Im this chapter the concepts of pct cammunicaion architecture 
Will be elucidated in detail, "We all casty the notion of «pat system 
and ‘develop a means for formally describing the structural composition of 
such a system. We will also informally introduce the concept of correctness 
for packet systems. The machinery needed to formally define end prove 


correctness will be developed in Chapters 3 and 4. 


Packet communication architecture is a discipline dealing with a 
special class of systems known as packet systems. Packet systems are 
composed of independeatly functioning units, keown as modules, which 
interact only by passing information to each other. The information is passed 
in the form of units called packets. There is no centralized facility for 
coordinating the action of the modules. Data processing and communication 
within pecket systems are asynchronous, and the various modules operate 


concurrently. 


In a packet system, the various modules are interconnected through 
one-way data paths known as channels. A channel connects two modules. in 
a specified direction and is used to pass data from the first module to the 
second. Channels leading into a module ae called input channels for the 
module, and channels leading out are called output channels. A packet system 
has its owa set of input and output channels connecting it to the outside 


world. The other ends of these channels are never explicitly designated. 


The structure of a packet system is determined by the way it is 
composed from modules and channels, and always remains fixed for a 
particular system. Modules and channels within a system are uniquely 
named, Figure 2.1-1 depicts a packet system DAS composed from three 
modules D, A and §. There is one system input channel X and two system 
output channels Y and Z. The internal channel U connects module D to 


module A, and channel V connects module D to module S. 


Figure 2.l-l1: A sample packet system DAS. 


All data treated by a packet system appear in the form of packets, 
which are passed along the various channels of the system. Each packet 
carries a value of some type. The modules in a packet system all have the 
same basic principle of operation: a module receives packets on its input 
channels, processes them internally and generates packets to be sent out on its 
output channels. This principle applies to entire packet systems just as it 
does to their individual component modules. Packet systems are data-driven 


in the sense that the progress of a computation in a packet system is 
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determined by the “passage of “packets thraygh “the saretern. 


There are two ingredients which together ‘dqsermine the*behavior of 
a packet system: its structure and the behavior of its modules. “Thus, for 
_ instance, in order to describe how the system DAS .acts, ong must finst decide 
what the modules D, A and S do. We now describe the behavior af these 


three modules. 


All three. modules seeeive ond pass: Integer<valuad gadiests. ‘Module 
A, upon receiving a packet from its .imgut -cleannel U, ilies one ‘to ‘the ‘viatue 
and sends out the incremented value as a packet on its cutput channel Y. 
Module $ behaves identically except far subtracting one instead of adding. 
Module D duplicates. the See sending out identical copies 


on U and V. 


Given these descriptions, it is not hard to figure out how system 
DAS acts. Any packet japut Trom X is copied onto internal channels U and V. 
The packet passed on U will be incremented and sent out on Y; the packet 
passed on V will be dectemented’ and sent out on Z. Thus esch packet 
received by DAS causes two packets to be generated: a packst with value ‘one 
greater on Y ‘aa a packet with value one less on Z. 


It may saccur to some zeaders here that: these cherectertzations are 
incomplete. “There is avabiguity. da describing ‘wiieat heppens when ‘several 
Packets are to be processed in ssquance: in whet order are testiting ‘packets 
senerated and passed? Jn our exampis ‘we ‘ean reedive such ‘questions by 
stipulating that the gelative order of packets on @Uhanndél ts @hwajs ‘preserved. 
Precise methods for dealing with questions of thip- nature will: be ‘described in 
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the next chapter. 
2.2. A closer look at packet systems 


In this section the workings of packet aaa will be examined in 
greater detail. The first thing we discuss is one of the fundamental 
properties they satisfy: the internal resources of a packet module or packet 
“system may be allocated and utilized in any arbitrary manner as long as the 
specified operations will be performed correctiy. Consider, for example, the 
system DAS from the previous section when it is in a state depicted in figure 
2.2-1. An input packet with value 2 has been received on the X channel and 
processed by the D module, leaving copies of the packet on channels U and V. 
Another’ packet with value 5 is still waiting on channel X to be processed by 


the system. 


Figure 2.2-1: A sample state of system DAS. 


There are three actions that should now be performed within the system: 
(1) module A absorbing and processing the packet on channel U; (2) module S 


processing the packet on V; and (3) system DAS ee the packet from 
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channel X and initiating its processing in module D, The crucial property of 
packet systems exhibited here is that these three actions may be performed in =~ 
any order, serially or concurrently, and the ceseet opemtion of ‘aystem DAS 
will be completely independent of whatever pedicetae. order is chosen. It is 
this property that makes the behavior of ackat systems genuinely 


asynchronous, 


We can gain a better understanding of the action of packet systems 
by taking a more detailed view of the ‘operation of ‘their component. modules. 
When a module receives a packet from one of its input channels, it begins to 
Process the packet internally. Sometimes the only _@ffect of the packet's 
absorption is that the module's internal state may change, In general, though, 
the module's semantics may require that it generate one or. more packets to be 
sent out on its rater channels in reply to the packet received.. The 
sequences of packets generated by a module in reply to a packet received are 
said to be the module's response to that packet. It is important to note that 
a module's response to a particular packet may depend: on previous packets 
input as well as the designated oe: There may be an arbitrary finite delay 
between the time a module receives a packet and the time the module 
generates and sends out its response to that packet, The fact that packet 


modules and systems must be able to tolerate “guch delays is an essential 


consequence of their. asyachronous operation. 


There is a special protocol that must be fulfilled in packet systems 
for the transmission and ‘receipt of packets salons _ various modules and 


channels. "Suppose | a channel : conhects ‘patie: M1 to module ‘M2, as 


» St 


illustrated here: 


Figure 2.2-2: A channel in a packet system. 


It is desirable for module Ml ‘to have some way of knowing when it ‘has 
successfully sent a‘packet out on channel C.” The cdtivention that has been 
adopted is that when a packet sent on C from ‘MI’ ts réceived by module M2, 
M2 will send a signal’to’M1 ‘on channel C in the réverse direction to indicate 
that it now has the packet safely in hand: Such’ a signal is known as an 
acknowledge signal. It is. not until M1. receives: an-acknowledge signal for a 
- particular packet, that it knows it is done with,the-pracess of generating and 
sending that packet. .Thus, fromthe point of. view: of module ‘M1, there are 
three discrete staps in the transmission of a;.packet-generation, sending. and 
receipt of acknowledgment. . It. should Sacaeted that. mouule “M2 cannot 
generate output to packets it receives, £20iR, chansel C.until it has sent back 
on C an acknowledge signal for those packets. share js a caveat with regard 
to acknowledge signals: although they are sent in _Tesponse to every, packet 
transmission in a packet system, we zeae them as Part of the hardware and 


. not available to be manipulated by system designers. . 


The channels in a packet system are agsumed to. have certain special 
characteristics as transmission media, .The first, and simaplest, 4s. that any time 
a packet is sent out om a channel, it will- eventually :be received:.at the other 


end. A packet generated to be sent out from some module in a packet system 
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can never be called back. This means that sthenateat « medule generates 2a 
packet to be sent cut, it will veceive an acknowlelige .signal for the sama 
‘within some finite span of time. It is assumed ‘that the channels never 
“bresk” and that vecknéwledge signals will always to received by the 
appropriate modules. Failure of a¢mechaniam, for ‘the — ‘of verification, 
invalidates the entire aan ‘function, The ‘mae “of fault tolerance in 
systems ate beyony the .scope cf this sesearch. ‘Thus, petket .eomanunication 
architecture requites ‘that every packet. separated, sby: same candle: must 
actually be sent out and. sokaowledged seithin, ome Sinise time voxterasi. It 
should be noted ‘that this requirement ea sonsidenetian «af comectanas nether 
than performance, because packet aystens, ane zpeminindgpendent. 


A second dempeatenit gta it eames te -thett “if ‘a mbit ected 
2 ‘packet from ome cof: dte Gnpitt theamidie, hee “that packet init eave “been sent 
May -not-reseiwe =: qaoket ‘vom <dhaneit SS “cnitees ‘wendntie Wl hal diveaty went 
thet packet out .on ©. oe a ere a ‘that ne 


& third characteristic of channels is ‘tat they act as FIFO queues, 
which ‘peeeds Aha i the eotule AL stove sends a packet out con channel 
and then sends another yackst y out on C at a later time, then M2 must 
receive and acknowledge x before y. ‘We mete he Further senusaytion that 


* Pe. Ae Se 
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Physically speaking, this assumption. is not realizable in Seietali because no 
real device can have infinite capacity, let alone a high-speed transmission 
medium. However, if we assume the unbounded buffering, then we rule out 
the ‘Possibility of system deadlock caused by packets piling up in bert’ 
channels and inhibiting further packet output into those channels Unbounded 


‘buffering ‘{s therefore a convenient asomrce to make, 


Finally, we » shall assume that for each chegaast in. a packet system 
there is a designated set (type) of =e that may be passed on the channel. 
For examnie, one — may carry ‘only integer packets, while another 
channel may accept only packets that consist of an employee, Rame together 


with a corresponding identification number, 


There is an extremely important property of: packet systems which 
we will be treating, namely nondeterminacy. A-module: or. system is said to 
be nondeterminate if its semantics: allow. two--or more distinct possible 
responses to a given packet input. A simple example of a nondeterminate 
module is one that models the toss of a coin. It has one input channel and 
one output channel, and its response to any packet received will be a single 
packet with either the value “heads” or the value "tails." The choice is 
arbitrary and independent of the Anput packet. . Nondeterminate modules and 
synienis a very difficult to. work with because. the multiplicity of. possible 
results is cumbersome to model mathematically. We will. explicitly allew for 
nondeterminate modules and systems in our treatment. 

A certain class of nondeterminate system ‘behavior will be of 
particular interest because it arises fréquently in the design of packet systems. 
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This kind of erste concerns the telative araee of. packets sent out on a 
channel, Consider a aystem in which the task of senarating and sending out 
packets in response to inputs taken from a specific channel is relatively 
complicated or ‘itumsconedming. One would. naturally wish to allow the 
processing of distinct inputs t0 proceed concurrently if possible, But then it 
may turn out that responses to a recent input will be ready to be sant olt 
before responses to fas Pacis ved gaviiee. sicneenee: it cannot be determined 
in advance whether or not such “cutting ahead" behavior will actually occur. 
It is possible to impose a | synchronization discipline that wal force the outputs 
into a desired order, but in doing so all the advantages of asynchronous 
processing of different inputs are lost. Thus, if the system application and 
design can tolerate “cutting ahead,” it is wise to allow it. In general, then, 
providing for nondeterminate behavior thet involves ‘different alternative 
orderings of generated output packets should often in practice become an 
attractive design goal for packet communication erchitecture. 


2.3. Correctness 


The notion. of correctness for packet systems bears a _ close 
relationship to the ways the issues of system structuring end. composition are 
treated within the framework of packet° Communication afchitecture. At a 
very intuitive level, a system ts correct if fi satisfies certain conditions laid 
out for it in advance. For packet. systems, these conditions take the form of 
behavioral specifications. As-we mentibuba in the scdceding chapter, a packet 
system's behavior is observable by the way it responds to its inputs. More 
precisely, the behavior is a relationship between inputs xemived and outputs 


‘system is behaving. correctly. Since modules pperate asyact 
arbitrary finite. delays, ene. cannot tell if additignal 


weilerated in response to those inputs. A packet system, therefore, is correct if 
this relation satisfies a given set of specificdtions. “The nature of such 
specifications will be discussed in detail in subsequent wack: . 

It is important to note that one cannot prove correctness of a system 
without some knowledge -of its internal workings...If system is viewed as a 
“black box" (figure 2.3-1), 


| Figure 2.391: "Black box" view. of a packet. systen. 


then the only things that can be seen are packets entering and leaving. There 
is simply not enough information available, to..determine. whether or not a 


mously and with 
output . packets are 
forthcoming. For. example, suppose a. system bas. already sent out all the 
packets jt should transmit in xesponse to some particular input, The module: 


only appears to be behaving correctly, since there is no gyarantee that an 
_ invalid packet will be unexpactedly sent, out later.. Even if this were 
-Geterminable, observation alone coujd never suffice ..to decide whether the 


system would respond correctly in al] situations. The only way to tie down 


‘he notion of correctness for a particular packet system, thessfore, is 10 open 
‘the system up and look inside: 


Figure 2.3-2: Internal view of the same packet system. 


If we view the system as being realized in terms of its component modules, 
then the following fundamental correctness principle becames evident: 

A packet wsiea is correct if its given structural 

decomposition satisfies the behavioral specifications: for 

the system whenever the component modules satisfy 

their own respective behavioral specifications. 
The notion of a system's éecomposition satiéfying « set of ‘specifications is not 
yet formally Gefined; it will be treated if detail in Chapter 4. The notivé of 
a module satisfying specifications is simply that of a pliysical device acting as 
intended, The above correctness principle defines only a relative nature of 
system correctness. An obvious question that arises is how to establish ‘the 
correctness of the modules in order to show the system correct, We already 
have the answer to this qusttinns just as with the system itself, correctness 
of the component modules can be established only in terms of their own 
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respective internal structures. 


A. significant ramification of this approach is that packet systems 
and modules are really two differant: views of the same thing: a middule is 
revealed to. be @ system when one examines-.its internal structure, . and 
ignoring the composition..of. a packet éystem is just: the ‘sane as. regarding it 
as a module. There is an underlying source fer this oDaceptuel unity, which 
is that. packet commusication architecture suppeeis the: hterarthical structuring 
and composition of systems, .-Packet systems: ean. (amd should) be designed so 
that there are distinct and well-structured levels.-of: Seoem position, each level 
consisting of systems built up from Saree: ae In this sense, our 
' fundamental correctness principle for packet systems aes a top-down 
| verification. methodology in which. correctness proofs. ase: broken: adown level 
by level into their natural logicel and. cangeptual,. constituents. . Logically 
distinct lines of argument are isolated so.that they genaat. interfere with one 
another. Thus the notion. of modular,.and -Ajesareshical system: structure is 


carried through in the approaches we take to correctness and verification. | 


It. may seem for.a moment that there is a potential infinite regress 
in working with smaller and smaller modyles within ‘mndules, but this can 
never arise. There is always a well-defined bottom Javel. to the hierarchy in 
which the modules are regarded. as.implementing primitive operations such as 
adding and gating. .At this point, correctness. hasbeen reduced to the way the 


primitive functions are defined. 


Our approach to correttness and ‘verification of packet systems 


allows.a‘system to be viewed in two different ways: ‘Internally, in terms of 
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its structural composition from modules, and externally, by Saabpaltag the 
internal workings. The idea of distinguishing between internal and external 
views of systems is clasely related to the notion of data abstractions in 
programming languages [Liskov -and Zilles, 1974]. ‘As we shail see in 
Chapter 3, it is feizly straightforward to construct. Behavioral specifications 
for a packet system viewed externally. However, in order to establish 
correctness of a system, we need to show: that. ‘thie external ‘charatterization 
agrees with the system's.structure. It is a difficult task: te formally ‘describe 
the behavior of a system in. terme of its internal: composition. We shail 
address this task in Chapter 4. 


2.4. Structural descriptions 


The only means we heve used sé°fér to describe the structure of 
packet systems is through informe!’ biock diagrams. Tf any general assertions 
are to be made involving system ‘composition; ie wiil'‘nesd a more precise 
vehicle for structural. éesertption.’ Such’ e ‘technique ”ts introduced in this 


section. 


The structure of a packet system may be* ihodeled in very 
straightforward fashion “by a @trected graph in ‘which ‘thodes representing 


modules are. comnected ‘by directed arcs: repitisenting chatinéis:’ Figure 2.4-1 


shows.a sample packet: system ‘sagetter with’ the dtrected ‘graph’ that models ‘it. 
Note that the directed graph has an extra fiode labeléd “s". This gives 
explicit representation to the system's "outside world” which serves as both 
the source of system input. channel. X and the target of system output channel 
Y. The graph may look like just another stylized drawing of the system, but 


tary 


aoe Boe a 


Figure 2.4<1: “A packet system and {ts diraécted graph. 


{ 
it is a mathematical object of specific charactaristics., Formally speaking, a 
Gitected graph is an ordered pair of the form (N, A) in which N is the set of 


its nodes and A is the set of its arcs, Each arc in A is an ordered triple 


containing a source node, an arc namie and a target’ node. An arc aéA has the 


form (a.source, a.name, a.target). For exaniple, the gaph in figure 2.4-1 is 
the ordered pair i. . | ee : 
LesDsE,F}, ((xyXsD), (D,PLE), (EQeF)s. (FeReD), (E,Yox))- 
It is easy to see that for each node n in the directed graph we can define the 
* $ts of arcs leading into and out of n. Thése seté ate given by ~ | 


of 


inputS(n). = {a€A: a.target =n) and outputs(n) #°{aeAt ~a.source = n}. 


“The directed ‘graph’ characterization thus ‘mathematically specifies how the 


modules in a system are interconnected. 


| ‘There are two additional propérties’ of packet’ systems that can be 
incorporated into our formal stractural’ desefiptions, “Pirst,-we can model the 
packet type restrictions for the channels by associating a type description with 
each channel. Second, we can specify packets initially present on the 
channels with an initial packet sequence for each channel. Both properties 


are handled easily in the directed graph model by adding extra fields to the 
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arcs. 


The above mathematical model for -packet system structure may be 
sugared into a structural description language. The description language we > 
use here is patterned after the structural portion of ADL as presented in 
[Leung, 1977]. For the system we have been discussing in this section, if we 
assume that all channels carry only integer valued packets ena that there is 
one packet with value zero initially present on channel R, then the formal 
description of its structure may ‘be represented as Totlows: 


System SYS 
inputs X( integer) 
‘outputs Y( integer) 
internals P( integer), Rt integer), A integer) 
Submodutes: 
D tnputs X, R&R; outputs P 
€ inputs P; outputs Q, ¥ 
F inputs Q; outputs ® 
Initially RO> ; 
While descriptions of this form do not explicitly name the source and target 
modules for each channel, these are very easily determined since each internal 
channel in the system must appear exactly once in a submodule input list and 


exactly once in a submodule output list. | 


This section has presented structural specifications for packet 
systems. The next two chapters present a model for behavioral specifications. 


Sat = 
CHAPTER 3: SPECIFICATIONS FOR PACKET MODULES 


3.1. The slice relation approach 


Because of the way a wacked system re built up from component 
modules, the behavior of a system will be a fuaetias ‘Of its: structure and the 
behavior of the modules in it, In this chapter we:ahall develop a method for 
formally specifying the behavior of packet modules.:..Specifieations defined by 
this method will be called external specifications. because they describe the 
behavior of packet. modules, without considering: theis. internal: structural 


composition. 


A packet module has a fixed numbér of input channels on which it 
receives. packets to be processed, and theré ata a fixed number of output 
channels on which it sends out packets in responge to the inputs it has 
received. A formal ‘ehavioral specification for a module must be able ‘to 
rigorously determine for each input exactly what ix a valid output response. 
Because packet systems are in general ndndeterniliiate, ‘the potential 
multiplicity of valid output responses rules out’ a difect functional mapping. 
Instead, we-shall supply: external specifications for’ a iiodule M in the form of 
a relation EXT, that formally relates inputs to the’ semantically valid 
corresponding. outputs, Such a relation will te called an external 


characteristic relation for the module M. 


The most obvious approach is to use a relation from input packets to 


output packets, but this does not suffice in even the simplest case: consider a 


module ID that “does nothing," that is, sends out tts input ‘packets untouched. 


—n}— 
Figure 3.l-l: The identity module ID. 


The ieee relation EXTp om packets defined by the equation 
| (p,q) € EXT if and only if'p <q 

does not completely descrive.the dehavier of the module ID. ir 1D receives as 
input a packet with value 1 followed by a packet ‘with value 2, there are 
two different possible:responses: [D can send ‘out the 1 foltowed by the 2, or 
it can send out the 2 first and the 1 later. Thus a specification for the 
module must describe the sequencing of packets.in oner to completely capture 
its behavior. For example, if we iatend for the module,iD. to preserve the 
relative order of the packets it receives, then its -pehavior would be correctly 
specified by the identity relation EXT» teken over the aomein of sequences of 
packets rather than individual packets. Such sequences are required .in 
general to describe the behavior of a module when it depends on a memory of 
previous packets received in order to decide how to respond to a. given ‘packet. 
We therefore need to develop some mathematical machinery for manipulating 
sequences of Packets. We will use the term stzeam to. denote’a sequence of 
packets. The mathematics of streams will be discussed in the next section. 


In general, the behavior of a module is specified by a binary 
relation that relates presented inputs to valid output responses. For the 
module ID, we see that presented input may .be correctly modeled by a stream 


Se i Ee ee 
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of packets passed on the input channel X. For a module with an arbitrary 


“number of input channels, in order to model “presented input we need a 


separate packet stream for each input channel. We therefore define an input 
slice for a module M to be a collection of streams, one for each input channel 
of M. Similarly, an output slice has as its components one stream for each - 
output channel. Thus the formal specifications for a module M will consist 
of a binary relation between input slices a output ‘slices, This relation is 
called the characteristic relation for uM We reserve the notation EXTy from 
now on to denote the characteristic “relation for a  apaule: M. . The slice 
relation approach to module specifications is not original, and a corresponding 


definition may be found in [Dennis, acini ae 


As an example, an input slice for the mod ie J shown below is a 
pair (wy) in ‘which u and Vv are packet streams for channels U and V, 


respectively; an output slice for J: has the ‘form (2), nee z is a packet 


stream over Z. 


=F 


Thus the characteristic relation: EXT, for J wilt have elements of the form 


((u,v), (2)). 


Slices distinguish the time ordering between packets passed on each 


individual: channel! but ‘not between packets’ ‘on ‘different channels. It may 


seem that cfucial behavioral information is lost by not imposing a total 


ordering on all packet transmissions into and out of a module, but this turns 
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out not to be the case. If a packet pl is sent out on a channel Cl in some 
packet system before packet p2 is sent out on channel C2, ‘there is no 
guarantee that pl will arrive ahead of p2 in their race to their respective 
destinations. This is because asynchronous packet systems Aaupose _ BO 
“constraints on transmission times along channels, allowing for different 
channels with different characteristics suited ta thetr needs. Thus, the extra 
information obtained from interstream packet ordering is rendered useless by 
the properties of channels in a packat communication system. The use of 
slices in our model, then, provides exactly the information needed for proper 
behavioral spaciticaeinina | | | | | 


3.2. Streams and their operations 


In this section the baste definitions, —- and aneeragce! 
properties of streams are laid out in detail. Because of the technical nature of 
the material, ani: tilileer: $0: thie. teetatioies nik “Aadieninal Seca ie pemuiibed in: ai 


Appendix. 


For any arbitrary packet module, we take as given for each of its 
input and output channels a well-defined space (set) of packet values that 
may be passed along that channel. The space, which we call a channel space 
for the channel, is identified with the Channel and heres the same name. 
Similarly, elements of a channel space are identified with packets. passed on 


the channel. 


We will define a stream to. be a sequence of packets passed: on a 
particular channel. Individuel packets in a stmgam Z will be seferred to by 


expressions of the form zl 1. A stream z will be denoted by an expression of 
the form etl), 2[2],.. 5. Streams may be finite or (countably) infinite. 
‘The size of a stream z, written #2, is the number of packets in it. Two 
streams" are equal ‘it ‘they have the same size and corresponding ‘packets in 
“them are “erual. This means that a stream, is uniquely determined by its size 
and by its elements and their ordering. "The space of sreamns for a channel z 
is denoted. dy 2". Formally, we have: 


Defin ition: A set S of natural numbers is said to be an initial segment of 
the natural numbers iff for any i.¢ S, j <¢ i implies j « S. 


Definition: A stream over a space Z is a function mapping some initial 
segment of the natural numbers into Z, The space of all streams over Z is 
denoted by Z*. 


Definition: The empty stream over a space Z, denoted by € or by (), is the 
unique stream over Z having empty domain and no elements. 


Definition: If 1 is in the domain of a stréam Z,--we define the /-th element 
of Z, denoted 2[1], to be the image of / under z. 


Observe that 2[1] is undefined if i is not in the. domajn. of . and that if zl ij 
is defined then 24] is defined for all J e 


Definition: _ For any stream 2Z, the size of z, de oted #2, is. the number of 
elements ‘in the domain of z. If the domain of z is infinite, then we say 
#Z = wo, 


Note that ‘zti] is defined if and only if 1 < 1< < #2. In particular, z[i] is 
defined for all natural numbers if and only if ‘#z = «; 


Definition: -Two streams z and 2’ are ‘said to de equal, written z= 2', iff 
fz=eziandz[i]=z[i]foralig#. 2 
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. In our treatment, we shall regard the tekan “a” a a distinguished 
natural number wise arithmetic weonertled are defined in aa obvious manner, 


such as 1 Sw and #1 © for al totem numb 1 The value © may 
or may ot be counted in the range of matural number quantifiers, this 
depends on context. Because all streams are countable, om expression such as 
zie] has no meaning, even when Z isan infinite etree. . 


ee 


An important relation over streama is, the; grefio. relation. ; pean Z 
oe ee oe ee eee = "occurs" at the baginaing of 2’ mares 


2x eat 
oie bara eg 


: . ' ‘ : ° 
a ae one” eas - 7 F4 $ 4 
z bakes & 


‘In such a Case, the stpeam diffevence: 2.0: Z shell be: the: postin @f 2 


omy, 5 ie Perens’ 
of eg 2 bu ERE OE 


occurring after the prefixz, 0° 


For any strait 2, we vie the‘ special Rotation! {k:n] 10 denote, the 
segment of Zz consisting of the k-th “through ‘mth elements of z in order. 
z[k: ia] is a stream of sie’ a-kel, and Wwe ilow the special case of $8 infinite 
stream when a = «, “A > my then aC kcw] Ha the eegey strom, As a: special 
| case, whenever k $ #@, 2C1:k] is the unique peefix of 2 of length &. This 


means that 2[1: KIC = 24] fer. eagh.§ Ske 


Given. streams. Z)..and Zp. we cat eee eee 2; @ dg, 
which is a stream consisting of the peckets ii'z, ‘followed by thw ‘packets in 
Z2. The formal definitions now follow: 


«Az < 


Definition: Given two streams 2, Z' over the space Z, we say z is a prefix of 
z', denoted Z PREFIX z', if and only if 

(1) #z § #z' and 

(2) “4 § #2 => z[i] = 2[i]. 


Definition: For any stream 2, if k ¢m< #z, then z[k:m] is the unique 
stream of size m-k+1 such that 2[k:mJ][i] = 2[k+i-1] for each i in its domain. 


Definition: Given streams z and z' for which Z PREFIX z', we define the 
difference Z' - 2 by 2' - Z = z'[1l+#z:#z']. 


Definition: For any two streams 2; and 2, over the same space Z, their 
concatenation Z, @ 22 is the unique stream Z of size #Z, + #Z2 satisfying 
zli] = (if i ¢ #2, then 2,[i] else Zo[ i-#z, ]). 
There are two stream operations we will use which count and find 
particular packets in a stream: count(p,z) is the number of packets in 2 
equal to packet p, and index(p,z,j) is the position in z of the j-th occurrence 


of packet p. They are defined by: 


Definition: count(p,z) = card{i < #z: z[i] = p}. 
Definition: index(p,2,j) = (if Ji ¢ #2: 21] = p & count(pLl:i-1],Z2) = jel 
then 1 else undefined). 


This is well-defined since if such i exists, then it is uniquely determined. 


Two more important relations over streams are the subsequence and 
merge relations. A stream Z, is a subsequence of stream Z, if the elements of 
Zz, occur in the same relative order within 2,. They do not have to occur 
contiguously. A stream 2 is a merge of streams Z; and 2, if and only if 2, 
and Zz occur in Z as disjoint subsequences and together exhaust Z. All merges 


of Z, and 2, are of length #2, + #Z2. The formal definitions are: 
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Definition: Given two streams z, and Z over the space Z, we say 2, is a 
subsequence of 22, denoted z, SUBSEQ 2p, if and only if there. exists. a function 
f that maps the domain of 2; into the domain of zy such that 

(1) ky < kg => f(ky) < f(kg) and 

(2) for each K <M, zitk] © zeff(k)], 


A function f satisfying properties (1) and (2) will be called an insertion. 
Any subset $ of the domain of a stream z defines a unique subsequence of Z 
which is formed simply by arranging the elements of 2. indexed. hy S. in 
increasing order. 


RQefinition: Given. three stresms.Z, 2), 2p ayer a, common, space-2, we say Z is 
a merge of 2, and. 2p if and only if the demain of .z can. ye partitioned into 
two disjoint subsets, one. defining 2; <s naee 6 ee 
defining Z, as a subsequence of z. 


This concludes the presentation of the fundamentals of streams. 
&.3. Examples — 

In this section we exhibit some elementary packet modules with 
their specifications, The first module we describe is the disirifute maiiela D 
(figure 3.3-1). 


ae eg ee 
Figure 3.3-1:. The distribute module D. 
Input slices for D belong to ge (streams over S) and output slices belong to 


Re x Y" (pairs of streams over R and Y, reepactivaly) This gives us the space 
for the characteristic relation EXT, ¢ sy x Re x Y")). Within a pocket 
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system, module D has the general function of distributing. packets through the 
system to places where they need to be routed. There are no restrictions on 
the type of packets that may be passed through D. The behavior of module D 
is to pass unchanged copies of input packets from: § onto both output channels 
Y and R. The response of D to an input stream s is the generation of two 
output streams r and y identical: to-s. As with all the modules we describe 
here, this works for infinite streams as well as finite streams. Thus the 
behavior of D is defined by 
((8), (r,y)) € EXTp « reyes, 

We give a couple of examples of the behavior of D, one input streams $ 
together with valid responses r and y: 
8 = (8,1,6,4), F = (8,1,6,4), y = (8,1,6,4)5 
8 = (1,2,3, eed Fo 1,2,3, weedy 21,253, oweds 

The negation module N (figure 3.3-2) processes. boolean-valued 
packets, sending out for each input value b . sacket whose. value is the 


logical negation not(b). 


—fif— 
Figure 3.3-2: The negation module N. 


An output stream y will be a termwise negation of the corresponding input 
stream xX. Formally, EXTy ¢ ((X*) x (Y*)) and | | 

(00), (y)) € EXTy <=> #y = #x and y[1] = not(xli]) Vi < #y. . 
An example of the behavior of module N is: 


Fy 
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. *% = (true, false, true, true, false), y = (false, true, false,false, trus). 


The edder module A (figure 3.8-3)- paisa up: dntteger-valued pockets 
in corresponding positions in. its Anputatrpamis: xX and 1,” adds: the palys and 


oo 


sends the sums out as a streamonS. oe oe eee 


%_ Soe 
R a | 


Figure 3.3-3: The adder module A. _ 


If one input stream is longer than the other, the exive Beckate absorbed from 
the longer input stream are not reflected in the output a This is 
specified by EXT, ¢ ((X* x R*) x S*) and | 

((x%,r), (8)) € EXT, <> #8 in, *) = sti] = x13 + - Vis #s. 
As examples, we have: 
x = @B,1,-6), r= (3,-5.6), 8 = (11,-4,0) 
x = (4,-9,0,-18), re 0), BC) 
MS (1,3,5, 606,241, ood, FB (2,4,6,..6,24,-00), & ® (2,0) s -eiWbelys si: 

A slightly more complicated module is the cumulative edder module 

C (figure 3.3-4) for which each packet ‘genarated for output on Y is the sum 
of all packets received on X so far. 


Figure 3.3-4: The cumulative adder module C. 


We specify the behavior by EXT, ¢ ((X*) x (¥*)) and 


(0x), fy) € EXT <=> y a! and vt] 2 +3 as Vi < #y. | 


As examples of the action of C, we have: . 


x = (4,2,- -1,0, -6,3), "ys (4,6,5)5,-1,2h 
xed), yn)” . 
Xm (1,3, 5,750 00p2teLy ceed, Y @ (Lyh, 9,16, cee ttyoveds 
One of the modules we will be discussing later on is the feedback 
modified first module F (figure 3.3-5), which handles integer packets. 


Figure. 3.3-5: The feedback.modified first. module F. 


Packets input from Uo are copied directly onto output : chains! Y. In addition, 
the value of the first “packet input pene U (if. there is any) is suitably 
modified and the resulting vave = outeut asa packet on V. For the purposes 
of this example, we shall say that. the. ‘first. packet value is modified. by 
adding the number four to it. ‘The :beéhavior of F is “ specified “by 
EXT ¢ ((U*) x (V* x Y*)) and 
((u), wy € EXT, <=> y = u and #v = min(l,#u).and v[i] = uli]+4 Wi-< #v. 
As examples, we haya: 
use, Vv w 4nyaie aku abuue, 
u = (1,2,3), Vv = (5), y = (1,2,3). | 

A module with an interesting logical function is the true gate T 
(figure 3. 3-6), which alts up integer Gata inputs from channel . X with 
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boolean control inputs. from chanel C. If the canprol, signal. value: is true, 
‘the corresponding data-'input from X is passed. cut: on Z. If the: contro} signal 
is false, the data packet is discarded. Thus the control signal stream C filters 
out specified elements of the data stream X, C must carry. tealasn packets, 
and X and Z may pass: packets of any type as long, as they: agree. 


Figure 3.3-@: The true gate T. 


The behavior of T is specified By EXT, < (Oe % Ce) x ze): and. 


(Ose), (z)) € Are <=> #2 8 fount(trus, TUM ge 
: ‘aad 1] 1 = adden trum, #7] v4 < re. 
“AS examples, we have 


= (1,2,3,4,5), © = (true, false, true, true, fatse), z = 0,3, 
© (6,75, © = Sales, trvestrue), ze (7. 
te. = (8,9,10,11), € = (false,toug, true), Z ™ (9510). 


The above modules are all determinate, ‘ince fdr any input ‘slice 


‘there is exactly one owétput’ site’ 'that  ctinstitutes a walt 
behavior is therefore functional. Our specification uneiet may’ be applied 
to nondeterminate modules as well, as we now ihiw. 


* 


4 


The nondeter minate merge module J (te 3.3-7) sends out all the 
packets it receives from input chaniels U'and V onto output channel Z. Tha 
‘of packets on cach of U and V is preserved, but the: packets 


relative | 
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coming from these two channels are arbitrarily interleaved on output. There 


is no restriction on the type.of packets that may be passed through J. 


UR oe 2 
El ee 


Figure 3.3-7:, The nondeterminate merge module J. 


We may specify the behavior of J by EXT, is ((U* x ve x a) and 

((u,Y), (z)) € “EXT, wa zisa merge. of u and Vv, 
where the notion of a merge of two. streams was defined in the previous 
section — to be 8 stream containing ‘the “two ‘given streams as disjoint 
subsequences, ‘The size of an output stream. z wil always 1 be tne. sum of the 


sizes of the corresponding ‘input streams’ U ‘and \ v. 


As an 2 example | of the behavior of ay i it ts given, as inputs the two 
streams us (1, 2) and vs 3, a, thea “there are six _ possible valid output 
responses: (1,2,3,4), (1,3,2,4), 1,3,4,2), (31,24, 43,1,4,2) and 43,4,1,2). 
The output response (1,4,2,3), however, is not valid, since the relative 
ordering of 3 before 4 in ‘the ‘input stream v has ‘not been Ririctdes on 


yt 


output, 


Ta PEAGUCE a wide variety ‘Of “nondeterminate behavior can be 
realized by constructing ayes formed by interconnecting various determinate 


modules with instances of the module od: In this. sense, the, nondeterminate 


merge module J is often viewed | as a a “source” of nondeterminacy in . 


packet systems. 


3.4. Evaluation 


We have. seen how the. -sttee-relation “‘approach - to ~ nodule 
specifications works for some simple cases. In this section we address the 


question of applicability of our r method 4D aoe complicated modules. 


The examples we meen treated only packets of elementary types 
(integer and boolean). One“of ‘the arehs of “fextbility in packet communication 
architecture is that systems may be. gasily pesigned to process, packets. which 


are een complex data structures, such — 4 personae), Foggras. Data items 


in the various fields of a ,_ Srgcrare- veined | packet, may,,.pe. Progassed 
concurrently in different internal sections, ofa ; a system. Direct support ,for 


Marte | Hav’ 
handling packets with arbitrarily complex structure 1 is. equally easy, in,.o 
pei dacs hk CEs fe GGine oh 
specification model. All that needs to be added, are ro, stream, and - visit 
operators for building and decomposing structures, and this is well understood 
ts (oe othopie 2b oo ot, ok te tervaded oar fa Shamitad 67 a 

and straightforward: Htructures ‘are seoetialy labeled rae poe of 
ets Hf) os YOoRas s a 

their components, “ahd ‘basic. ‘operations on. rane have ae found in 
ar ey Ae wae ee OF ore as ee rN a 


ih cael ‘languages for a ‘long ‘time, 


Ente aoe eee 
1.5! Ss 


The basic ‘question to be discussed here is now. effectively our 


<iK ‘ Se hS 


Spetifieation Aechnigues can model the function! capabilities. of modules _ that 
are to be physically realized in hardware i packet Acne We claim 
that the Slice-relation ‘escriptive formalism has ‘Sufficient power of expression 


eam) tosis Barigogets b 
to“ model ‘the behavior of any realizable a module. There are several 
factors that siibstantiate this claim. Our’ jechaians allows the use » of arbitrary 
hgwarate os < ey ges sg 
matheniatically’ ‘Getined functions and “predicates on packet alae. ‘and streams. 
racemes SS 


Basic operations on packet values may be composed through ‘the use oe 


i 
i 
H 
; 


conditional exptessions and recursion on streams, © This ‘places at our disposal 
the functional capabilities of the textual language used to model data flow 
schemas in [Weng, 1975]. Thus, from the stand peter of Turing computability, 
the slice-relation approach can. ‘model . behavior of mad desired complexity. 


hee 


Kigacbhal a module's characteristic relation acts as a predicate that asks of an 
output slice “is this a correct. reponse to “the ‘presented japut?" ‘Thus, 


ant 


external characteristic relations ae “the way our model mathematically 


determines correctness i modules in packet yeas, 


nad 


The above arguments say. nothing about the complexity of behavioral 
descriptions in our model. It is an unfortunate fact that as processes one 
wishes to model increase a compexity the effort Requires to formally 
specity them increases even ‘more rapidly. “Although ‘this appears to be the 
case with packet modules as well as with computer Programs, 1 it i ‘oped that 
the hMerarchical composition of packet ayeiems, can ‘Teduce the structural 


complexity to - be handled if. ‘not the ‘functional “complexity. ‘Behavioral 


oh ae eu 


specifications for the structural compodtion « of racket modules into systems 


a ‘ 2 


are treated in the following chapter. 


a 


The “external specifications “described. in ‘the ‘previous chapter 
constitute a formal way of defining how: a packet aroun is to interact with 
its outside world. “The most important conceptual property here ie that 
system is correct whenever is satisfies its al specifications. ‘As we 
mentioned earlier, correctness “of a pee oo established by outside 
observation ‘alone; it is necessary’ to analyse the’ taverhal operation of a system 


in order to prove ‘correctness; 


Structurally speaking, a pocket mien panes of a collection of. 
component modules interconnected by channels, “The behavior 6 of a: system is 
determined by ‘two things: its ‘enchant ‘at the ‘pahavior of its component 
modules. A formal description of a system's behavior Which is besed entirely 
on these two ingredients will be called a set of internal specifications for 
the system because $¢ axpremes the syitem's action ia terms of its internal 


composition, 


In order to show a system is correct, two steps must be taken. 
First, one must produce a set of internal specifications for the system. These 
internal specifications then must be proved equivalent to the system's external 
specifications. ‘The logical reasoning involved here is that the component 
modules are assumed to be correct from the beginning; this assumption is then 
used throughout, the system correctness proof. If one wishes to demonstrate 
the correctness of a component module, it is decomposed structurally into its 
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own components; this module's ‘correctness is ‘verified 2 the exact same 
manner as the entire system. la this way the hierarchical syeun suuctunne 
provided in packet communication architecture supports hierarchical 


aencruring of system ‘verification, 


#. 


To formally derive the internal “specifjcations for a packet system, 
| two pieces of information are needed: _f1) & structural. description of the 
system, and (2) the external ‘specifications for gach. of its component. modules. 
It is not necessary to examine the component modules internally, since they 
are assumed correct. The internal specifications will take the identical form 
as the external Specifications, namely a ‘binary relation betwar 


, input slices 


and output slices. 
At first glanes; coming up. with “‘titernal ‘epdeffications for a packet 


system may. appear. to. be a, straightforward: -task.. Coasider; for example, the 
system; $1 shown: in figure 4.t-t. 


F igure 4.1-1; System $1. acts by functional compostsion. . 


‘Suppose that module *F pete a function f ‘to each packet value x received on 
: a om 

%, sending thé resilting value f(x) “out as a pocket on i If F Preserves 

‘packet ordering, its characteristic relation Ext, would contain all ordered pairs 


((x), ‘(y)} for which y i% the stream obtained ‘from stream x by poe f to 
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each packet of x in sequence. In other words, . 

(09, y)) € xT; <=> ty = #Xx and yli] = rox 1D Wi< #. 
If module G applies : a ‘function g in the same manner, 1.¢. 
| ((y), (2)) € EXTg <a> #z = Hy and 21] = o(yliD vi < #2, 
then it is easy to see that for each packet entering the system $l, first f and 
then g is applied. The behavior of si, then, is the functional composition of 
modules F and G. It is therefore a trivial matter to ‘ow that ‘the internal | 
specifications for $1 match’ thé characteristic relation. 

(0), Ze EXT ey’ <> 42 «ie and ZL i] « (FL 199) Vi < #2. 

One could ‘take a far more ‘om plicated’ ‘exampie, such as a system to compute 
roots of quadratic equations which is com posed from modules that take square 
roots, multiply by four, divide two values, and the like. ‘There wrouiia ‘be 
long chains of functienal composition, . but::peeducing: internal specifications 
would present nq. major probleme. Even: for. néadeterminate systeth, one 
could simply compose weistiane instead of functions, Sé:it seems, at lest so 
far, that internal specifications are simple indeed to determine. 


There turns out to bea very large fly in the ointment. 
Figure 4.1-2 depicts a system structure for which functional or relational 
composition is of ies use whatsoever. The. ayclic. interconnection structure 
imposes mutual data dependencies between channels Q and R. Packets passed 
on channef‘R from module’B depend’ on the packets received by B from 
channel Q, while the packets passed on Q depend on earlier packets received 
by. module A from channel R. It isa aisinctly nontrivial | task, to express the 
stream R in terms of the remaining streams x, Q and Z, since packets passed 
on R will in general depend on packets previously papsed on R, This kind of 


__ particulay prespnted input is, characterized by a t 


Led 


Figure 4.1-2: Cyclic data dependencies 


dependency introduces mutually recursive ‘systems of equations: expressing the 
channel, streams.in terms of one another... Gilles.Kahn,[Kahn,.1974] has found 
a way to. solve systems of this kind through the use.of mathematical theory 


Of fixpoints.. His technique, howeves,. requires that the modules be 
determinate, and there is no straightforward way. to. apply his. techniques to 
. nondeterminate systems, The task of -deyiving: internal specifications for a 


packet. system is a challenging problem, and.a new appepech 4s required, 

The approach “we willbe using ‘is based oa an: operational view of 
systems. ‘We model the operation: of a-syeterm Dy reverdiig: the progress of a 
computation in a. series of internal system .states, The system's response to 


eordered progression of 
internal states, which we call an execution sequence. In general, there are a 


_ large. number of possible execution. sequences that correspand to a particular 
_ system response to: some presented input. A system. property. we.’ 


to prove must be. shown to held over ell possible execution sequences that 


f introduces some of 
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the basic characteristics of execution sequences. 


4.2. Exeoution sequences (introductory). 


The progress of a computation in a packet system is modeled. by the 
succession of internal states in an execution sequence. We will be. defining 
internal states so that a state incorporetes. for each channel. the cumulative 
stream of packets Senerated to be pace: on that — This. determines, in 
particular, for each state the input slice presented. to. the system and the 


output slice: generated, by. the. system 80 far, 
f sceopure ae sie Giaean Gubuioae ts aes is“ that’ one: can 


construct a system state that? represerits the commpatatioa: running to 
‘completion. For sith a state, the ottptt slice: réprésertts: one- of’ the systém's 


possible ultimate resyonses to’ its‘ presented: input: Sudli“an: execution: sequence: 
will be said to seelize thet perticalar output redpdase to. tlie system's 


presented input. Ht will then be « straightféewerd- task to” produce’ the 
system's internal. sripcifications, which. are..givep, by, the. relaiion. between input 
slices. and. comrespensing. output slices reslized. by: some execution sequence, 

A partfeular kind of phyédicat event we wisli to model in an 
execution sequetite is the transmission of''a: packet’ on: sorte: channel: The‘ act 
of a module sendttig a packit out on a chanwel itray*oocur’ at’ any moment 
between the time the packet is génerated by’ the module and the time: the 
module receives. ail’ acknowledge: signal for the paciest:- For anygtven: instant 
of time during such an’ interval; the packet: may or miay’ not: have been sent 
out already, and we-cannot determine which isthe case, Thus, owr execution 
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sequences will capture two kinds of events: generation of a packet and 
receipt of the acknowledge signal. Because we do not know the actual 
moment of transmission, a packet will be regarded as only potentially present 


on the channel during the interval between ‘these two events. 


Each state in an execution sequence must reflect the relevant events 
that have occurred in the system. The events described above are associated 
with particular channels, so we may partition state information into 
components relating to the individual channels in the system. To model a 
State, we give for each channel the cumulative sequence of events of each 
kind (packet generation and acknowledgment) that have taken place. Packet 
generation events are handled by giving the stream of generated packets for 
each channel. Since the inatiais act as FIFO queues; the packets that have 
been acknowledged are always given by a prefix of the generated packet 
stream. We call this prefix the acknowledged prefix of the stream. Thus 
every state in a execution sequence consists of a generated packet stream for 


each channel together with its acknowledged prefix. _ 


Another significant property of execution sequences is that they are 
to exhibit the behavior of the component modules of the system. At any 
state, for each module the generated packet streams on the module's output 
channels must constitute a valid response by that. module to the input packets 
it has recelved (and acknowledged). , | | | 

A transition from one state ‘a the next in an execution sequence 
models the physical occurrence of a “module receiving new input and 


generating new output packets in response. ‘If there are no more packets 


generating new outa’ packets in TeSpenee. If there _are BO more _ packets 
waiting to be abyorbed by modules in the system, the syytem state will 


remain constant, 


We now give. some examples of execution sequences: for a particular 
system S shown in figure 4.2-1. | 


1 . 
x! uo ty 
t ' 

1 4 
t t 
i} ‘ 

H 
Vv ' 
18 ‘ 
| eS er rere J 


Figure 4.2-1: & samplé packet systes S 


J.is the nondeterminate merge module and F is the feedback modified first 
module; both of these modules were described in the previous chapter. 
Nondeterminate systems such as S may Generate different output responses to a 


given presented aes: This will be —— ia our — 


. An execution sequence is ‘represented bya ‘table in which the rows 
are the internal states and the columns correspond. to channels. _Each entry in 
the table is the _ appropriate stream of generated packets with a heavy’ dot 
marking the end ef the acknowledged prefix. 


Execution sequence 4, shown in figure 4.2-2, models a particular 
response of system § to the input stream (1,2) presented on channel X, We 
also give a corresponding series of snapshots that illustrate the internal system 
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states during the computation. 


state xX U Vv Y 


Figure 4.2-2: Sample execution sequence A for system S. 


The snapshots, shown in figure 4.2-3, depict the first seven internal system 
states captured in execution sequence A. In state 0, the serdenee 41,2) of 
input packets has not yet entered the system to be gtocessed: and no packets 
have been acknowledged (all the heavy dots are. at the left-end of the channel | 
streams), In state 1, the first packet (with value 1) i been received and 
acknowledged by module J, and a copy has been generated to be sent on 
channel U. This copy is, by the time of state-2,-received and acknowledged 
by module F. F generates a copy for sutput on Y, and also a packet with 
value. 5 (1+#4) for output on V | (since the packet 1 was the first packet 
received by F on U). In state 3, the input packet 2 will be passed by J onto 
U, and in state 4 it is generated as output on Y. Note that no further packets 


are generated for channel V. By state 5, the packet with value 5 has been 
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processed by J, and by state 6 it has been passed through F. State 6 shows 
that system S's response (1,2,5) to its input (1,2) has been completely 
generated for output. By state 7 (not shown), these packets have been sent 


out and acknowledged by their outside world recipient. 


We now present another execution sequence that models the 
response of system § to the same presented input stream (1,2). Execution 
sequence B, shown in figure 4.2-4, is identical to execution sequence A 


except for states 2 and 4. 


Figure 4.2-4: Sample execution sequence B for system S. 


From state 1 to state 3, this execution sequence has module J receive and 
process the packet 2 before module F processes the packet 1 reversing the 
order of these two events from the way they were in execution sequence A, 


Similarly, from state 3 to state 5 here, J takes in the packet 5 before F 
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processes the packet 2. The snapshots of states 2 and 4 for execution 


sequence B are shown in figure 4.2-5. 


ee ae 


state? © ee nes 
Figure 4.2-5: Snapshots for execution sequence B. 


Observe that the two distinct execution sequences: ‘A and B model two distinct 
computations for the “system S, doth ‘resulting in the same system response 
(1,2,5) to the presented input a, 2), “On: the other hand, execution 
sequence C, shown in . Tigure 42-6, “models _ a computation in which the 
system produces a different response (1, 5, 2) to : to the same input. This sequence 
is identical with execution. sequence a through state 2, but now module J 
processes the packet 5 from channel ve before it takes the packet 2 from 
channel X. This dittarance is what. canens. the — in system response. 
Snapshots for the resulting. states 3 through. 6 for execution sequence C are 
shown in-figyre 42-720 200 woe ss pees 


oe 


It is amportant a note ae a ad ume ‘during a comparation. = a 
packet system, a packet that has been generated to be sent out on some 
channel may or may not actually ‘have hast ant sont already. After the 


packet is acknowledged we know it has ‘bean sent ‘out, fase before 


state xX U V Y 
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Figure 4.2-7: Snapshots for execution sequence C, 
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acknowledgment it is only potentially on the channel. “Potential” packets are 
guaranteed to have been by some future time .eventually passed on the 
channel in the relative order given, but we can draw no stronger conclusions. 
This means that in all the snapshots we have depicted here, the packets 
shown on the various channels rang at the indicated time only potentially 


present. 


This concludes our informal introduction to execution sequences. In 
the next section we shall motivate and discuss the properties that will be 


used to characterize them formally. : 


4.3. Properties of execution sequences 


In order to formally define execution sequences for a packet aysiem: 
we need to. carefully motivate and discuss severa) properties that characterize 
them. We shall be using as an example a particular packet system Cc 
composed from the modules A and D as shown in figure 4.3-1. The left half 
of the figure shows the system structure pictorially, while the right: half is a 
textual representation that provides a formal weevetaral : description of the. 
system. Once we characterize execution sequences for C, its internal 
specifications will be the binary relation between presented input slices. and 
‘the corresponding dutput slices that ase) scdlinsd as the system's response to 
the given input by some execution sequence. This, of course, will provide a 
formal behavioral specification for C expressed.in terms of the above 
structural description of C and in terms of the characteristic relations EXT, 


and EXTp for the component modules A and D. In thé previous chapter, we 


System C 
Inputs XCinteger) 
outputs Y(inteager) | 
~ internals SCthteger), » RC integer) 
Submodu les 
A iWiputs X, R: outputs S 
; inputs S;_ outputs R, Y 
Initially R<O> 


Figure 4.3-1: Realization of a sample packet system Cc 


specifically defined the external specifications for A and D, but in. our 
treatment-here the characteristic relations ‘shall be viewed" abstractly. 


An execution sequence is a time-ordered, progression of internal 
states of a packet system, and a state gives particular information about each 
channel in the system. ‘The state information for a channel Z at any given 
moment contains, as we mentioned earlier: both the stream of packets 
generated to be passed on Z and its acknowledged prefix. The space of 
streatns of packets passed on Z-is denoted by Z* and’ includes infinite as well 
as finite streams, For any stream z ¢°Z*, we denote its acknowledged prefix 


by 2°. A channel state for Z will then be an orderdé pair of the form (z,zZ°). 


The state information ‘for a vem is simply the collection of state 
information on all of its channels. For our sample system c, define the space 
CSYS* ‘to be the cartesian product of the channel packet stream spaces X*, S*, 
R= and Y*. Elements of CSYS*, which are “called system slices, are denoted $ 
(the dollar sign is pronounced “slice” {) and are tuples of the form (x,s,",y), 
‘where x, 8, fF and y: are streams of integet ‘packets, A system state will 
consequeiitly be an ordered pair of the forii’($;$"), where the’ acknowledged 


prefix $3 of the slice $ is the tuple whose components are the acknowledged 
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prefixes of the respective components of §. 


We have alresdy defined input aad output slices for modules. in a 
packet system. The space of input slices for a module is the. cartesian product’ 
of the channel stream spaces: ‘for the module's fs tap chennele output: slices are 
similarly built up ‘from the module's output channel stream spaces. For the 
module A in our example, these two spaces are AIN® = (X* x R*) and 
AOUT® = (S*); for the module D nay are DIN® = (S*) and pOUTs # (R® x Y*), 
The same thing cam be done .for the system © by: viewing it. as «module: 
CIN* = (X*) and COUT= = (¥*), Thus, the, charactesiatio: seletions, for: the -aystem 
C and its two component modules A and D are oven, by EXT. s (X*) x (Y*), 
EXT, ¢ (OK* x Re) x (S*)) and EXTp ¢ Cor x ee x Y*)), © We will have 
((x), (y)) « EXTe if and only if the output stream y ts a valid response to the 

input stream x ‘under the semantic properties of the system C, 


Execution sequences for a pecket system. will be of the form 
{($,, $°)}, where 4 takes on.natuzal aumber -yelyes. starting from zero. §,* 
Will be the acknowledged: prefix<of, the..i-th system: slige: $.° There are a 
number of semantic properties which. an: execution. qpquence must satisfy in 
order to correctly model the aire of a packet syne. we. describe them 
hate in terms of the sample packet system Cc, noting that the generalization to 
arbitrary “packet systems ‘presents no ‘difficulty. | _ For. the system . G 


components of "system slice $ are denoted by $= % &, rs Y). 


The first condition an execution: sequence: must; satisfy: is that. there 
be a valid initial system state,, To. express, the. property: that. no packets: have 
been. processed at the start, we requive that. the inisial state (@g:fig’) Reve an 


ae 
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empty acknowledged prefix $4. The components of $ *ceirecponding to input 
channels must match. the presented input slice; In our case, this means that 
Xo must be equal to a given stream x of inputs, And it must aiso ‘be the case 
that the other components of $) agree with the initial: configuration defined 
by the system structure. For system (C; .this -‘wequires that) we have 


$o = Yo 3-e (empty streams) and rp * (0) (stream of one ‘Zzero-valued: packet). 


An execution sequence is supposed. to reflect a system's response to a 
particular presented input slicé, and this input slice ‘appears in its entirety 
“within the initial system slice $o._ inorder for “the. execution sequence to 
realize a response to precisely this input ad nothing more, we just have at 
‘each system state the identical input slice az at the beginning, which for the 
system C means that x, ® Xo for all i. Physically, this requirement amounts 
to the outside world “suspending additional input ‘to ‘the system ane ‘the 


system completes its résponse to the input ‘already presented, 


The third condition that must be fulfilled is agreement with the 
semantic properties of the coinponent’ inodules of the system. ' What this 
means is that for all states it must be true of “each Biodule that the. packets 
that have been received and acknowledged by. ‘that ‘module are related through 
‘the module's chavacteristic relation to ‘the sdtout ‘packets "sanarsted by that 
module. In our system, the semantics for the A module impose ‘the condition 
((x;3, 7,4), (8,)) € EXT,, and the rD module forces Us, a), cc “to, y) « EXTy. (The 
reason we specifically remove the stream To is ‘that Mt ‘represents a packet, 
stream that is initially present but is not generated as S output by any module.) 


These conditions must hold for each i indexing some state in the execution 
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Sequence, starting from the initial state with 10, 


The fourth. property that showld hold within an execution .saqivence 
is rather complex. We wish -to state -precienly the equipement that state 
transitions within. an execution sequence must agree with the - system 
. structure. Each state (%,,, $,,°) must fedlow from ats prededexsor <6, $*) in 
@. manner coasistent with the physical arrangement iof the Jsystem's chapmels. 
Once a packet is sent out along a channel, it can never be “unsent” or called 
_ back. For each channel Z in the system, packets can only. be added in going 
| from one state to another. Moreover, since the channels act as -FIFO queues, 
new packets conaet disturb the relative order of previous packets. Thus, for 
- each channel z, the channel stream Z; must be a subsequence of Fiat for all i. 
| | This requirement also holds separately for the acknowlejged prefixes on each 

.channel, ‘since acknowledged packets cannot become “unacknowledged,” so we 


must also have zi" asa subsequence of Z,," for all, A, 


ft would greatly simplify the technical . development in the 
following section if we could strengthen this fourth condition to require that 
z, be a prefix of Z,, rather than any subsequence. As it stands now, we are 
requiring that a module can only send out additional packets in response ‘to 
new input packets received. “Insisting on a | prefix property would impose a 
time Fearicuen on the intervals from packet generation to packet transmission, 
forcing packets E) be ent out on channels, in the exact ‘same order in, which 
their respective sprocesses of generation ‘were initieted. Unfortunately, | this 
turns out to be too strong a stipulation. If a module such as M 


(figure 4.3-2) receives from its input channel] X first a packet p and later a 


packet g, it may very well take M longer to produce a packet p' in response 


to p than to produce a packet q’ in response to @. 


Figure 4.3-2: A module M. 


This could occur naturally in applications such as,a cacghe/bulk memory or an 
information retrieval system. In order. for M te, derive the: benefits of 
asynchronous operation, its behavior..should be specified. nondeterminately so 
that either stream (p',q') or (q',p') will be a-valid respense to the input stream 
(p,q). Figure 4.3-3 depicts the two corresponding exegutian. sequences, which 
should both be valid, | 


(a) 
Figure 4.3-3: Two execution sequences for M. 
In execution sequence (a), channel stream y; # <p’) ‘ts a prefix of channel 


stream y, = (p',q'). However, in sequence (b), the packet g' has cut ahead of 


the packet p' by the time state 2 occurs. This is legal, since the p' packet is 
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only potentially present on Y during state 1. So for sequence (b), y,; ® (p') is 
a subsequence and not a prefix -of Yo a (q',p'?. In ‘fact, there is ‘no way to 
realize the response described by execution sequence (b) if we insist that y; 
be a prefix of yo. We need the generality of the subsequence relation to 
realize “cutting ahead" behavior of this nature in packet systems. Thus we 
cannot strengthen the requirement that each channel reid in an execution 


sequence be a subsequence of its successor. 


We -can, on the other hend, strengthen this subsequence property to 
use the prefix relation in the case of a¢knowledged prefixes of channel states. 
The “cutting ahead" behavior es described above ‘cannot ‘occur withiti the 
acknowledged prefix of a channel stregm, sikce we know that all the packets 
here have already been pessed. This means that fui any execution sequence, 
the only way 2Z,," may differ from z,* is through the appéniiing of newly 
acknowledged packets to the end of the stream. Thus z® ‘cannot be just any 


subsequence of Z,,°; it must be a prefix. 


The fifth and final condition that must. be satisfied by an execution | 
sequence is that no channel may receive acknowledgment for a packet that 
Was never generated as output to be sent on ‘that channel. This is guaranteed 
by requiring that for each i the acknowledged préfix z,,* must be an initial 
segment of the previous stream Z, on all channels Zz 

The notion of execution sequences that has aa developed here 

models the progress of a computation within a packet system, but ; there is one 
| final element that is missing: | the idea of ultimate result of a computation, 


We must identify when a packet system finishes reecting to its input as well 


oe Tae 
as handle the cases of infinite inputs and infinite responses to finite inputs. 


This will be done by developing the concepts of limits and completeness for 


; execution sequences, 


_ For any packet system, we may define a relation PRECEDES on system 

states by (8, $*) PRECEDES (6, §)") att (6 PREFIX $* and § SUBSEQ $). 
| Intuitively, increasing values with respect to PRECEDES, snacete forward 
"progress of a ‘computation withia a packet system. In PAEUCULRE, 
S1 PRECEDES 82 must hold whenever system state $2 is reachable from system 
state S 1 in some computation through the processing ‘ot edditional packets. 
We may observe that “PRECEDES is a transitive relation. Furthermore, by 
‘condition ( (4) above, an execution sequence ts monotonically increasing with 
respect o: PRECEDES. An Upper bound of pee execution sequence, then, 
corresponds to a euapetesion that has progressed. at least as fer as all the 
states in the sequence, while a least upper pound indicates that no ‘extraneous 
computation is taking. Place. We define a mit of a execution Sequence to 
. be a least upper mur with respect to ‘the PRECEDES relation, Taus, a limit 
of an execution sequence corresponds to. a ree, state, in which all the 
computation specified by the 2 sequence runs to completion. This notion applies 
‘to infinite as well as finite computations, We use the notation 
lim {(s, $5) = oe (8 hy to denote the limit east, upper bound) of an 


execution sornence when it is wall-defined and d unique. 


It may be obeet ved: that the PREFIX Felasion, isa partial order and 
that for any execution sequence {$;, $%) the sequence {$; i*) is monotonically 
- increasing with respect to PREFIX and “always has a uniquely defined least 


De. ee 


upper bound $,,* = wk (i). These facts are proved in ‘the next section. 
However, least tGngae bounds are not necessarily well defined with respect to 
PRECEDES, We therefore need some ‘additional "properties. to be satisfied by an 
execution sequence in order to guarantee that Hmits exist and ‘are well 
defined, 


Consider a system state (8, $*) in which : isa proper “prefix of &. 
The nonempty difference slice $- s* would represent pockets that have been 
Senerated put not yet, acknowledged. “Such a state can never represent a. 
complete computation, since’ ‘it specifies packets still awaiting ‘Processing by 
various internal modules. If the system is to fully respond to its inputs, all 
the packets that have been generated at any time during a computation mus 
eventually be acknowledged. We thus define an execution sequence ($, '$®) 
to be complete if and only if for each i there exists @ Jj such that 
$, SUBSEQ $?. This j will be the state by which time all packets that uve 
been generated by the time of cue i will have been sent out and 
acknowledged. In general, in any state ($, $*) for which $ = = 8%, there are 
no generated packets ‘waiting for "processing and acknowledgment, so the 
system cannot perform any further actions, We prove in the next section 
that . any complete execution sequence ES, sé yy has” a unique and well 
defined limit (8, $,,% for which $= $,". This result will be known as 
the Limit Existence Theorem. Thus the notion of a ‘computation running to 


completion within a packet system is always well defined. 


The Limit of a ‘complete execution sequence should always — 


the state of the ‘systeza = icigaaastae its. ultimate, output response to ‘the 
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presented input. For a given input slice, we call such a state a limit state, 
and we say that the slice consisting of the streams for the system output 
channels in a limit state is an ultimate output slice. The presented input slice 
and the ultimate output slice may each be finite or infinite. If either is 
infinite, there will be infinitely many states in a complete execution sequence 
and the limit state will not be one of the states in the sequence. We shall 
adopt the convention that execution sequences will always be infinite. If 
both the presented input and ultimate output slices are finite, then the limit 
state will be an element of the execution sequence, and all succeeding 


elements will be identical to this state. 


There is a class of pathological conditions under which the limit of 
a complete execution sequence fails to represent the system's ultimate output 
response to the presented input. Consider the case of a module M 


(figure 4.3-4), 


P Tr] Q 
Figure 4.3-4:; A discontinuous module. 


which outputs the empty stream for finite input but which echoes any 
infinite input stream. The external characteristic relation EXTy is given by 
EXT, ¢ ((P*) x (Q*)) and | 

((p), (q)) € EXTy <=> (#p < © and qse) or (#p = «© and q=p). 
In response to input streams p; of increasing finite length, M will not send 


out any packets at all, and the limit of a complete execution sequence 
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modeling this behavior will exhibit an empty ultimate output stream q,. But 
this disagrees with M's specified nonempty response to infinite input. The 
problem. lies in the way EXT, is specified; we may avoid this by. seguiring 
that all modules in packet systems be continuoug, which means that the 
responses to an increasing sequence of input streams must tend fo an 
apprapelane: well-defined limit. .. When this is the case, We are ‘@Maranteed 
that, the limit of 9 complete execution sequence does in fect properly capture 
the system's ultimate output response. | 


We now eve -descrited. ali the rdeviat cheractwristics of exevution 
sequences, The mathematical development follows. tn the méxt. section: - ~ 


4.4, Execution sequences (formally) 


We now, give the formal characterization forthe notion af execution 
sequences that has been developed. First, we show an example; afterwards, 
we give the definition for the general case. Consider the sample system C, | 
which was discussed in the previous section and a shown here again: 


f (eo a = System C 
' - inputs X(tateger ) 


_ outputs ¥{ ioteger). 


7 


internals S(integer), R( integer) 


—s les egos bog e+ 

A inputs X, &; outputs S 

D inputs S;-owkputs 8, Yo 
Initially R<O> 2-5 


{ 
i] 
t 
' 
i 
’ 
t 
' 
i] 
’ 
4 


£ i 
4 


Figure 4.4-1: Realization of a sample packet system C 


we have the following characterization: 
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An infinite sequence ({($, $°)} in which for each natural number 
$° = (x9, 9,9, 7°, y,9) is an acknowledged prefix of $ = (x, 8;, Tj, ¥;) will be 
an execution sequence for C if and only if the following five conditions holds 
(1) [initial state] $,* = (e .€,€,€), %& = Yo s«<«, “Tp = (0) 
(2) {input suspension] Xi." Xp for all i 
(3) £ consistency] Vi: (x8, ri*), (8) « ExT, and (8,2), (r iso» y) € EXT, 
(4) [FIFO] $* PREFIX $,,° and §, ‘SUBSEQ $1 for all i 
(5) [connection] $.1° PREFIX §; for all i 


An execution sequence {($, $,")} for system C .is complete if. and only if 
Wi J: $, SUBSEQ $@. , : 


Note that although the PREFIX and SUBSEQ relations were defined over streams, 
they are being applied to system slices here. ‘the latent is for these Telations 
to be taken componentwise over all ® “ctiannei” streats, “which: means “that one 
slice is a prefix of a second: if and anly 4€-each: component clbannel .stream. in 
the first slice is a prefix of the matching channel ‘stream in the: second ‘slice. 
ica ce are treated in the same Bway: 

The above formal characterization of execution ppetuences for the 
system C may be extended to arbitrary packet systems ‘with no difficulty. 
The formal structural definition for a packet orem is of the general form 

System SYS” 
inputs W(---), 26, X(e9-)- 
outputs Y(---), ..., Zle-e) 


internals U(---), ..., V(-=-) 
Submodu les 


M daputs P, ee Q; Gutputs R, Co) ee” Ss . 


Initially U<u0>, ..., VCvO>,. YeyO, ..., 1Kz0>. 
The parenthesized items are channel packet types ‘atid may be‘arbitrary. (The 
use of consecutive letters in the alphabet ‘sepatated by ellipses, such as 


"P, ..., Q" allows an arbitrary number of items in between, so that for 
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example a submodule M of the system may have any : number of input 


channels.) 
The generalized definitions now become: 


Definition: A sequence {($;, $°)} of system states for a system SYS whose 
structural description is as given above Will be an execution sequence for SYS 
if and only if 

(1) [initial state] $54 = (é,...,€), Up * 0, ..., Vo * VO, Yo = yO, ..., Zp = 20 

(2) [input suspension] Vi: W, * Wo... %& ® X 

(3) [ consistency] For each module M in SYS we have | 

: ((pP oer 9), (P;-gs-.+)8;-8)) € EXT M 
(4) [FIFO] $* PREFIX and &, SUBSEQ $,, for all i 
(5) [connection] ,," PREFIX $ for all i 


Definition: An execution sequence {(,, $*)} fora system SYS is mare if 
and only if Wi 3j: §; SU8SEQ. °. 
We will thus be able to give internal specifications for any packet system. 


The relations PREFIX and SuBSEQ were defined in section 3.2. We 
now proceed to derive the basic mathematical properties for these two 
relations and the PRECEDES Pelation. This will lead me to a proof of the Limit 
Existence Theorem, which states that limits exist and are well-defined for 


complete execution sequences. 


Lemma 1: For any space Z, the PREFIX relation is a partial ordering over Z*. 


Proof: The reflexive and transitive properties are clearly satisfied. Now if 
Z PREFIX z' and z' PREFIX z, then #z < #z' and #z' < #z, so #2 = #z' = N, which 
means Z and 2’ have the same domain. But then for i ¢ N we have 
z[i] = z'[i], which means z and 2’ coincide over their common domain. This 
forces Z = Z' and establishes the antisymmetry property, completing the proof. 


Definition: A. sequence {Z,) of streams is said to be. monotone if for. each ij, 
Zz PREFIX 2,.;. 
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Lemma 2: Any monotone meaence ) of streams has a walane and well 
defined least upper: bound. Pca 


Proof: Each stream 2, is a function that°may be regarded as a set of ordered 
pairs of the form (k, 2{[k]), Let 2 be the set-theoretie union.of all the Zj. 
Then Z will be a function, since any two ordered pairs (k, z[k) and 
(k, Z[k]) must coincide (by monotonicity), ‘1 is immediately apparent that 
zeZ* and Z is an upper bound for {z,) “under. PREFIX: Moreover, Zz will ‘be a 
least upper bound, since any Upper bound for {2} must contain all the 2Z, 
set-theoretically and hence their union z. Finally, uniquences follows from 
the antisymmetry property ‘derived-in Lemma ; 


femme Be PREFIX. is a subrelation of SUBSEQ: 

Proof: The insertion function required by the foriial definition of SUBSEQ is 
simply the meaty function. 

It is easy to see that the. SUBSEQ relation ts reflexive and transltive. However, 
it is not ‘necessarily antisymmetric! Consider the two infinite streams {0011)° 
and (0101)%, .each consisting of: ‘infiattely ‘hany cerds and ones. * These 
streams are distinct, but each is a subiequence 0 of: the other, Thus, SUBSEQ is 
not a partial ordering relation. _ oe 


The relations PREFIX and ‘SUBSEQ both apply to streams, but the 
PRECEDES relation will. be.taken over thannel: states; which we now define. 
Definition: A channel state for a | channel Z in.a packet system. is.an ordered 


pair of the form (zz) in which 2: ams +d are. guquentes - of - packets...and 
z® PREFIX z. 


Definition: : For ‘two: aa ‘states @,7,°)° and ee mi ‘we say 
(z,,Z;°) PRECEDES i 2a if and- only if § ‘SUBSEQ Ziet and 2° PREFIX Ze 


Definition: A sequence (a2) of channel states is said to be monotone if 
and only if (z,,z,°) PRECEDES 242i” for all i. 


Definition: A sequence {(z,,2z,°)} of channel states is said to be complete if 


and only if Vi 3j s.t. z, a oe 


It is gs teeataig impotent to Kote that the ielaens < PRRSEDES: ‘a. to. be a 
Partial order hecauge. of. ite SUBSEQ. component; . This-is,enaliy eoem im tee.case 
of the ‘two. chantie?: we oF and’ (Co OTT, o, itn having an 
pti. These, states. ara. distinct 


infinite stream and an empty seknowled od 
- and. each peeneaan the: ieatadchaestsen ‘antisyubmetry ‘paspersy fails ‘Were pane 


udase bs 


least upper ‘bounds for a Monotone “ tequdnce “a channel, states are not 


ot 


necoasatliy well defined, ‘However, coateunin: dacar wat ticions,aendision to 
guarantee that the least i tice smlqem Tre: follewing 
theorem PLOVeS . this fLant,..: ude Ga Lae SE yeaa gt 


; PEO es Se EY AS, tank 
heorem: If {(z,,2;°)} is a monotone and complete sequence of channel states 
_ . fy. and 

and it a5, * “aap oo ee 
equal. to. SZe)eieccs ve Bias Lg TR 


. Proof: .. Since 2, ie by definition: saiaiea tas ace have : 
— (1) . Mie PREFIX 2. 
Now given any “iny completeness we heve 
(2) 34s 2, SUBSEQ BAER 
But 2,3 PREFIX Z,, which by lems Simplies 
“say niBe 7 Ng ee 2* suatté z.. naka fe 
Since SUG5EA ie transitive: eaceseaeced Maipiytad. 
(4) 2, SUBSEQ z,,. 
The ¢ombidation of equations (1)"'axa (1) détablidties Boke) as Ce ‘epper 
: bownd for {(z2°F) water ‘the PREGPDES réféttin.” se 
In order to show that this upper bound is in fact a least ubper 
bound, we must esteblish that far aay enna Hater EAN or whishi:, 
(&) 7 aa PRECEDES (az™>; “ 
it must be the case that (Zesrq) PRECEDES gz". Now equation (6) sealed 
z suiSeq z ana z* babkre 2 THhll'the leeet'upyer bound z, of (E¥) ust be 
a prefix of the upper bound z*, ie. aia 


ae 


Boat? 


re i 
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(6) Z, PREFIX 29, 
But since (z,2°) is a channel state, 24. PREFIX Z,:s0 2, PREFIX-z, which implies 
(7)  Zq SUBSEQ 2. 


The combination of equations (6) and (7) yields the result 
(Z5:2q) PRECEDES (2,28), so we now have established that (z,,,Z,) is a least 
upper bound for (z,,2;%). 

The proof is not yet complete, . since the “PRECEDES relation is not 
necessarily antisymmetric and we must “therefore explicitly’ guarantee the 
well-definedness and uniqueness of the least upper ‘bound we produced. This 
will follow directly if we show that for any channel state (zz), whenever 
(Zo,Zo) PRECEDES (z,z8) and (2,2) PRECEDES. Cake) then’ it must be true that 
z=zisz.. Now 2z,, PREFIX 29 PREFIX z, implies ‘282 2,. Also, the 
combination 2° PREFIX z SUBSEQ z, implies #z9 < #z < #z,, and this "squeeze" 
condition forces #z* = #z, But since z* PREFIX %;. we must-have-z°.©z. Thus 
z=z%s22z,, which sets up the required antisymmetry condition and 
guarantees uniqueness of the least upper bound. This completes the proof. 


All of. the ‘results: established here have béel stated for individual 
channels in a packet system. -However, we may apply them to the internal 
behavior of an entire system in a rather strdightferward mdtiner. As an 
example, a system slice $ is a prefix of a slice $*°df and -only if each 
component stream in $ is a prefix of the corresponding component stream in 


$'. All properties of the PREFIX stream relation are: just. as valid for- the 


_ PREFIX slice relation. Similerly, all: properties of the stréam: relation SUBSEQ 


hold for. slices. Moreover, all ‘properties of the. PRECEDES: relation on channel 


. States apply to system states. In particular, the-féliowing theorem, which we 


call: the Limit Existence Theorem, holds: 


Theorem: If {($, $2) is a complete execution sequence for a packet system, 


and if $, = | sup {$*)}, than ee aa is ‘Well defined: and ‘unique 
and equal to ($,, $,). 
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‘We now give a formal definition for the notion of continuity, 
which was meutionell in the srevious ‘sectéon. Conténaity isa property of a 


module's externel chavacteristic relation, so we define it for binary relations 
over slices: 2 ; Piette eet 


Definition: A relation ~ on slices is continuous if whenever §,= sup (8). 
where the sequence ($,} of slices satisfies $ PREFIX $,, for all i, then 
(8,8) € ~ <a> Fa sequence (8) of streams such that _ 
GQ) 8,8) €~ for al 
(2) $ SUBSEQ 6," for all 4 and 
59-0." i (2 9 tr wet 


4.6. Charactertuation of internal apinttveutiins 7 

"Now ‘that we have defined eixecution sequences for any packet 
system, it is simple-to produce «system a imtexnal apecifications: The internal 
specifications for a. panket .aystem SY¥S.ersa binery:zeletion INT ys from. aystem 
input sliges to - system ‘output slices, which. we call; the system's diternal 
_» Cheracteristieretatien, For the sample;aystem © wa thave Seon disoussing; we 
haye INTs GOK) 0 (Y), end 4he dnternel specifications may” be>formally 
cheracterized. by: x), {y)) «aT. if end enily df therm: isa aomplets sexecetion 
sequence {(6,.%")} fer & such that p= X% aid Ye = y,. where Me and: y,, are 
defined by By * Op My for Ye) 2nd 8, 7. 9UB £8"}* (%,, Sey le, Yo). —Note 
that % represents the, jmitial input presented to C and that y, tepresemts: the 
ultimate output yielded by C. We can easily. generalise this te an arbitrary 
system by quantifying the condition %! =X over all Anput channels x. and 


quantifying, the. condition ¥. @ ¥ over a output: channels Y. . Nate that. the 
definition of INTgy, is in effect parameterized by the structural description of 


system SYS and by the characteristic ‘relations of the component modules in 
SYS. 


SoFhe 


The development of internal specifications for packet evaiains is now 
complete: We have two ways of formally describing the behavior ‘of a packet 
system: externally, in terms of its interaction with: the .owtside: world, and 
internally, in terms Of its structure and composition. We can apply this to 
_ correctness proofs by observing that a system. $YS ig corsectly realized by its 
internal structure if and only if its (external) characteristic relation :EXTsys 
and its internal characteristic relation INTsyg: are identionl.. A correctness proof 
for a packet system will therefore consist of a demonstration that each Of 


these two relations is contained in the other. 


Aside from the obvious application to system. verification, the - formal 
Specifications we have developed for packet systems. are valuable: dn achieving 
a. frequently overlooked objective: understanding tie. behavior of these 
systems. Our operational approach lets us model the activity: within a system 
step by step. The “dot. notation” tables for execution. sequences are a useful 
pedagogical tool, aiding in a person's conceptualization.of what goes on. in 
packet systems. It is hoped that even without going: through a process of 
formal verification, designers of asynchronous, nondeterminate systems will 


find the techniques developed here to be. of a stance in building packet 


systems. 


In: tds: chapter ‘Wes Mtscuse’ tie epglitesion ‘of’ our specification model. 
to the problem of ‘proving packet’ systems! correct. “+A: ‘packit “system fs‘'an 
interconmestion. off compenient: moduleé, aif ite beliavitr: is-fbrmally given’ by 
ita internal spedifitattons. Such ‘s: system will be correst tf tt‘ also satisfits a 
diven. ‘set: of external -spertfivetions: > Cobrecinésd* of ' & packet systeni, tharefire, 


| a the- agreement. between 6 suv af: intertal”ope dis atid a det Of exterhal 


ony 
» 


iuspemificattions;. EGE EE aay fee te had he Sty 


To prove correctness of a particular system SYS, cuacniust shove that 


- its ‘excternal  clsasacteristio: relation’ EXTyyy wndtti’ See ise sae tae 
INT oye. coincides. ~The paouf native sepabitie Hat ‘two ‘purts “namely the 
inclusions: INT gy ¢ EMT gpg dnd GMT ive ¢ INPalg: Phe: Titet! titcluston’ states tat 
Will be ‘provedby ahowibig: thet. for any- complete Gnbtiition sequence ‘for’ STS, 
the initial input: slice aid: the uithmate ‘(int stacd) olatpit tite are: reiaréd’ ‘by 
EXT gs. | Wer Gelb this-teie consteteney ‘portion of the’ proof, ‘ied ft Vurittes 


specifications may be realized by some complete execution sequence. ‘This is 


ic relation 


called the synthesis portion of the proof, since it involves construction of an 
appropriate execution sequence to realize each instance of system behavior. 
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The eunpiest example we can give of a correctness proof is for a 
system ID Composed from two copies NL and ‘Ne of the negation module N 
described in section 3.3. The structure of “this julen is shown in 


figure 5. 1- 1. 


Lemna aati ameter : is Systen, 10 
' inpéts:. X(boolean) 
1 
1 


i] 
1 
X } Y Zz outputs Z(boolean) | 
internals, ¥(boolean) 
pees or - " $qbmodutes 
‘ Io ‘ _N1 inputs X; outputs Y 


RS ECE ap ore ce ee eee ; NZ inputs Y; outputs Z 
Initially empty 


Figure 5.1-1: A simple system ID to be proved correct 


The behavior of ID is trivial: any boolean packet value coming in on channel 
X is twice negated, thus remaining unchanged’ conadeaeal Nl and N2 
preserve stream ordering and since the’ ‘channels are’ ‘an mre, the system ID 
sends out on Z the adeutice? stream received on x, So to “demonstrate she 


correctness of ID, we will have to show that its internal characteristic 
relation INTo matches the external characteristic relation 2 EXTg s (x) x (2*)) 
given by 
| (00), (2)) € EXTp <=> z = x, 

For the component modules Nl and N2, the external -cheracteristic relations 
~—EXTy, ¢ ((X*) x (¥*)) and EXTye ¢ (€Y*) x @*)) are given by 

(0x), (y)) € EXTy, <®> #y = #x and y[i] = not(x[i]) Vi < #y 
and (Cy), (2Z)) € EXTyz <=> #2 = #y and z[i] = not(y[ iJ) Vi < #z. 
Note that all three channel spaces X, Y and Z are equal to the set 


{true, false} of boolean values. 
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We can formally state the correctness ‘theorem for the given 
. realization of system ID. The definition of the relation INT is iacorporated 


rein a) 


into Nhe following statement. 


Theorem: ((x), (2)) € EXT <=> ((x), (z)) € INT) 

<=> 3 a complete execution sequence ({($,, $*)} for ID such that X%> = xX and 
Z. = Z, where X and Z, are defined ty $= (Xo, Yoo Zo) and 
$. = Sup 4 © or Yoor Zn): 7 


We recall the definitions of execution sequence aoa aainivticnes stating them 
for our particular aystem ID: A sequence of the form {S,, $°)} in which for 
each i $" = (x4, y*, z#) is a prefix of $ = (x, y, z) Will be an execution 
sequence for ID if and only if the following five conditions hold: 


(1) [initial state] $4 = (€€,€), Yo § 25 € | 

(2) [inpat suspension] — % = X> for ali 

(3) [coasisteacy} ((x;*), (y))) € EXT yg, and ((y"), (&)) ePT x for all { 
(4) [FIFO] (8, $)") PRECEDES. ($,,, %,,°).for all i. 

(5) [connection] $,,;2 PREFIX §$, for all 1 


An execution sequence {$;, $4) for D is complete if and only if 
Vids st. § SUBSEQ $*. Note that whenever this is true, the Limit ‘Existence 
Theorem guareatess that we will also have aU {$,, $4)» = ($,,4, $,.° 


where §,, # aup (8*). 


The statement of the correctness theorem for the system ID is now 
complete, and we ere ready to. begin developing «proof. 


FOE NRE BOR 206 a RD RE leat: 5 


6.2. Proof for the system ID 


We must show ‘that for the system 10. the, external ‘Telation EXTip 
and the internal relation: INTj9. coincide, Thie ennnesty portion of the proof 
involves ‘showing that INT; i S ExTo, which. “means “that for any complete 


BOS Sess 


execution sequence for. ID. the. initial. impas. Xe and. the. ultumate. output Z,, 
satisfy the characteristic relation EXT p. in Proving this, we need to establish 


a particular property “that wi be an important, _ingrediont in all our 


correctness proofs, This property,. Which we, ‘Sa galk: the ‘Limit Size Lemma, 
_ concerns the size of--channhel . sequetices”’ ‘tn a Miniit ‘state for a system. 
Essentially, it asserts that the size of each channel ‘stream in the limit state of 
an execution sequence is the limit-of the stzés ofthe’ Stréatas for that channel 
as one proceeds through the states in the ‘execution Hequence: Note that this 
property is not limited to the perticular: system 1D: wut ‘rather Holds for any 


system we will wish to prove correct, “The Limit Size Lémme ts ‘proved: by 
PEGS : 


using the least upper ‘bound property of the ‘mit state to establish the least 
upper bound property for the sequence sizes... ~ 


Lemma: In a complete monotone sequence {(z,, Z°)} of channel states for a 
packet system, if z, = nue {z,°}, then #2, = sup (#z} = Sup: {42,4}. 


Proof: The sequence {#27} is a nondecreasing sequence of natural numbers 
and must either be eventually constant or else increase without ‘bound. In 
the first cace, there exists a j such that Viod: “tee 2 ez), , which implies 
#z;)° = sup {42,9}. Now for any kJ, the” ‘combination ra = #z° and 
z° PREFIX z,4 forces z9 = 2,4. Thus z, = eee, {z*} _ Ww and 
#z, = #z° = sup {#z,4). 

In the second case, sup (#z,°} = ©, We claim #2, zo, If this is 
false, then 3N: #z, = N. But then (Wi: z* PREFIX. z,) implies 
(vi: #2; < #z, = .N), which would make N an upper bound for {#z;"}, 
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contradicting sup {#z*} =. Thus #z, = «© = Sup. (#%,"). | % S.. + 
Now by the Limit Exit ' Theorem, we have 
(ios Zu) ® ont up {@, 2%), which implies Vi: (,, z*) PRECEDES Wako) In 
particular, Wtr z ‘sist z,,, % Vi: Wz, $ Way which makes #2, an upper 
- hound for {4a}. Bub Mis af PROFIL a Mnpliga Visomy® ¢ 4g), 20: any upper 
bound for t (4) must be an upper. bound, for (4a) and mugt, therefare ‘be no © 


pbus 


{#4,} as well as for (#ay*}, wich comp the prtof” 


Corollary: If kéeo and k < feu ‘then there exists an 1 such that ne > k. 
Proof: Suppose ‘that for” ‘al i we had ra < < % This would “imply 


“amit Size, Lamama, a, is the. , lpast. “upper. bemink, 40 We must. have 
#2, $ k-1 < k, Which contradicts the hypotheats for finite k. 


_.Now that we have ‘proved. this: lammK, the. consistency: proof for 
system. !D_ is casy,,. We shall. wae the abbreviation I). in thie proof and .all 
others to denote. use of the Limit, Size. Lemma. . 


Consistency pragt: U,.we.are given a complete. axecutien, sequence.as in the 
statement of the correctness theorem for ID, we must show that if x = Mp and 
z= 2, then (Gd, (2)) € EXT.” this ts tr ian only'if & » , 0, 

#Z = 9X andct{d } =.nC+} Wi ga,” 
so we must verify both 4, size_Rropert ty 404 98 slamons seaparty, af Zo, 


We first note-that:dy the input suspension property: of an executton: seqrience, 
x, = Xo = X for all i, Be EE EY Te BB Fa, partleny #Xy. # HK. 


But then we have . de Pauls cate, + he 7 Art 
wpe) Us) 
= = euptey,*) (by EXT) als 
= Yoo. (LSZ) 
= sup{#y;,) ust) 
= sup{#x,;*} Coy EXT. wi) 
= oh, thst) : 


= mx, 
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which establishes the desired size property. 


~The element condition ‘ig equally easy. For any fiatiiral number 
k § #2, by the corollary to LSL we hava 31: #z;°.2-&... Now>we have 
| 2k] = Zot k] 

“* wzark] (since 2° PREFIX 2,) 
-@{k]... dinoe 2) PREFIX:2)) 
not(y@k]) (by EXTwo) _ a 
not(yk]) (since y," PREFIX y,) 
snot(nott<*(k})) (ey EXTy;) 
not(nat(x[k]) (since x9. PREFIX x 
= x(k]. 

This is the required element condition, and ‘the consistency ‘portion. of the 
proof is now complete. 


Ee 


ae hee ee ki 


The above censistency proof: may mpasee ste be. Felativeky intricate for 
“such a‘trivial system as 10, but it realiy isn't. “An ‘we really had to do was 
set up two simple chains of equality. that traced the interna). data paths. and 
applied the behavioral properties of the ‘Smponent Modules, ‘Fot noncyclic 


systems, this presents no ‘real difficulties. 


The synthesis portion of = correctness proof for ID involves 
showing that EXT oS INT, iD» For each See caput stream X and. each 
corresponding output stream Z, we need to: ‘eonsttact att execution sequence for 
ID to realize the appropriate system behavior. “Thus, given streams x and z for 
_ which . ((x), (Z))€ EXT we must realize the internal ‘chavior of IB by a 
matching meecution sequerice $o,.. rabies ‘tn which’ “each system “state $; is a 
" S-tuple (x, ¥;, 2) of dotted chaitnel states, “(The aot, as we mentioned earlier, 


Yaa 


separates the acknowledged prefix from the rest of a “channel ial 


6 (GO: 


Our strategy is to produce a general order in which the component 
modules absorb and process packets. The order we choose for these aciioné in 
the system ID is as follows: (1) Module Nl receives a packet p from channel 
X and generates its negation not(p) for output on Y; (2) Module N2 receives 
the not(p) packet from Y and generates a packet with value not(not(p)) = p for 
output on Z; (3) The outside world receives and acknowledges the p packet 
from Z. This sequence of actions is repeated once for each packet in the 
presented input stream X. Thus the execution sequence we shall generate for 


the given streams X and Z will be cyclic of period three. 


Synthesis proof: Given streams x and z for which ((x), (z)) € EXTip, we note 
that this means Z = xX, Let k#X (note that kK may be infinite). ..i let y be 
the unique stream of size k for which each element is given by 
yLi] = not(x[i]). 
For each natural number 7 starting from zero, define 

(O) $5, = (xC1:ijex[itl:kJ], yLlsij-, 221:i]+). 
This formula gives every third state in the execution sequence, For i=0, it 
reduces to the case of the initial system state 

$o = (xX, *, °), 

since the stream segments indexed by the expression [1:i] = [1:0] are all 
empty. 
For each natural number / starting from one, define 

(1) Soo 2 (xf 1l:iJexLitl:kJ, yLl:i-lJey{i], 2[l:i-lJ-) and 

(2) $3, 2 (<C]:ijexLitl:kJj, yLlsij>, 201:i-1]-20i)). 
These two formulas give all the system states whose indices are respectively 
One more and two more than the multiples of three. 


Together, the formulas (0), (1) and (2) define an infinite sequence of system 
States $o,...,8),... which may be verified in an extremely tedious and extremely 
straightforward manner to in fact be a complete execution sequence for the 
system ID. We will not go into the details here, since the remainder of the 
proof is neither interesting nor illuminating. We shall, however, make some 
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comments about the execution sequence we just onetet | 
First, we make some 2 observations about tis. states. In the i-th state 
LAG rat GE 7 ferry 


given by formula ( 1 ), the i-th packel XE] in the Aawat stream X has _dust 
been absorbed by module Ni, and its negation is seen as a newly-generated 
: (but not yet acknowledged) packet’ on” ‘chanel ¥. denoted by he "y{ij". In 
| the. corresponding (i-th) state given ‘by (a); this’ packet ‘has been received and 
acknowledged: by N2, and'N2 “has genetdted. a new packet with value zi}. 
“This ‘state is followed by the“ fth state ‘given by (6), which reflects the 


acknowledgment of the z[ i} ‘packet by the Outside World. ; 
tjas tet Gaede sds ct ; 
If the size k of the “input gebenes x is Siabedem then. the above 
& : WQeig yo 8 Dag oe aks 
os sequence of system stated will Tepeat endlenly after Sa. Kae: arate from this 
: i oz ise ea is . 


"point on will be identical, namely 
(") | ce ye, 2 a | 
In this terminal state, all the inpw-packetéo Rave Ween’ processed and™ a 


complete response has been passed to the outside world. Since the sequence of 
““gtates is eventually constant in this case, the Mmit re precisely this spepeating 
~ terminal state. In ‘the ‘case “of an ‘afinit input stream > x, the states in the 
infinite sequence are ‘all distinct, and the terminal rate given wy ( "ya above is 
‘the’ limit even though it does not actually ‘occur within the sequence. In 
“either Case, we note that the output treats” z ‘will be ‘Metical eh the input 
“stream x ae the hypothesis (00, @ € Xo ee a 
Wins ad - 


ara 
The execution sequences Produced. Jy. the. synthesis, Proof .do not 
‘exhaust all possible : sequences for the system. 10; nqwever,.. they. are sufficient 


to realize all legal behaviors for ID given by. Plo... ee 
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One trivial observation now completes the correctness proof for our 
realization of system ID. Since all three channels x Y and Z accept only 
boolean-valued packets there is obviously no ‘conflict between packet type 


restrictions. 


The proof given here may. seam. lengthy,. but: the, crucial logical ‘and 
mathematical arguments are brief and, straightforward... The place where we 
‘took the ‘functional composition of the two logical negations. te; yield. the 
identity relation was in the final step of, the consistency. paxtion of: qur -proof, 
when i used the property -notinatoxt k))..*.xEk]. . Other. systems. without 
cyclic data dependencies im ee Haterast ences are proved in similar 


ea 


fashion to ‘satisfy the appropriate composition of the external characteristic 


ae. 


relations of “their component " modules, 7 1 ‘the next _ section, We prove 
YEE LE at nee Hes TEE Py 


correctness for a system with cyclic structure. 


6.8. Correctness af a epcheloyuten: 


One of the sample packet sdetage we have already worked with, the 
gyatont Cc composed from the adder module A and the distribute module D, has 
a cyclic. interconnection structure, ie Bey em. shown again. . dn 
figure 5. 3- 1, " channels S and R form a "directed cycle. _We shall Prove the 
correctness of system c in this section, Ik is not hard to give an informal 
charactetization of the system behavior. Initially, wpadule A pairs up the first 
packet value input from X with the zero packet on channel R, sending out 
the sum to‘both ¥ and R by way of module D. This sum, once paneea around 
through R baek into A, is added to the next packet. input: ‘to A from x and 


the new sum is cycled around again on channels $ and R. In this way, we 
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System C 

Y inputs X( integer) 

outputs: Y¢integer ). 

internals SCinteger), R( integer) 
Submedules™ 

A inputs x, R;. outputs S 

D inputs S; outputs R, Y 
Initially ROy 


° 
t 
i) 
t 
i] 


tom an am on oy aD om an OP ae ow 


- Figure 5.3-1: The cyclic packet system C 


can see that module A computes a sequence of cumulative sums of packets 
taken from eas system input stream X. Thus the behavior of Cc is to send out 
on Y a stream of cumulative sums of packets taken in on X. _ We wish to 
prove that this is indeed the case; to do this, we shall make use of the 
formal specification techniques that have been developed here. 


We have previously given the exterpal characteristic relations 
EXT, ac = (OK x R*) x (S*)) and EXTp . «S*) x (R* x YO) for modules A and D. 
The relation EXTp is defined by | 

((), (r,y)) € EXTp <x) reyes, 
and EXT, is defined by 
(Ost), (8)) € EXT, <=> #5 = min(#x, fr) and s[1] = x4) + rEtJ Vi < ¥s. 

The external spesihicatesa for the ite C axe amici -to those ‘for the 
cumulative adder module C described in Chapter 3. The external characteristic 
relation EXTc ¢ ((X*) x (Y*)) is defined by f aan 


((x), (y)) € EXTc <=> #y = #& and yEid: = yp x04] vis n. ‘ 


In proving the correctness of system C, we ater “aioe that the system's 


internal characteristic relation INT, is precisely equal to EXT¢. The following 


ye DE REIS tery tM OTS WWMM eee ce tn te 
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correctness theorem for C incorporates the pea cara sd INT o. 


Theorem: (00, on <€ ‘EXTe <=> ((x), (y)) € INTo - : 

«> 2a complete execution sequance {(8,, 9") for C such that M = X and 
Yo © Y, “where xy and 'y, are defined by $= (or Son For Yo) and 
$.. = sup “(BS Bias has Fae Yo): 


Execution sequences. for: system C were fotmaily' defined in Section 4.4. We 


reiterate here that in an execution sequence {8 6") for C, each system 


RRO Eye 


- slice $, has the form s s =e a t ya aad “each scxnowiedged prefix $," has 


a nee spree ee 
the form $9 = (x, 7 of : “yn. “We are now v ready to develop the correctness 


pea WES e APPR 


proof for. system c. 


There are two Jemmas: we _ shall requiry that, dead. with the 
preservation of a certain kind of channel state relationship as an execution 


Pee 


sequence for the system cer is ‘taken to its Limit, “emma 1 is a basic erePery 
rs : 3 is “ise | ; ay 
of least upper bounds of sequences of natural sin bied. Lemma 2, which we 
Sitter cd el 


call the Minimum Limit Lemma, allows us te ‘drew a a significant oualusion 


about the size of certain channel steams in ‘te limit state of an SxECUTOn 


sequence. = 
Lemma i: If ‘{k) and {m,} are nondecreasing sequences of. natural ‘numbers 
amd k, << ta for. edohics; 20nd 46: k-* Sup{N} and wai sepfal}, then? k <m : 


Proof: For each: 2-vweei have ko <w Sm, ‘vow aw Upper bound for (&} and 
is therefore no less than the least upper bound ke 


Lemma 2: If {ki}, {m} and {nj} are nondecreasing sequences of natural 
numbers. such thet '&, «2nin(a,m) for atl 1, ‘and seid sup(k), w= sup{m)}, 
ne ‘sup{ni), thea ks * mina, n). 
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Proof: Wi: k, $m, so by Lemma 1, k <n... Similarly, k-< n, so k < min(in,n). 
We now show that strict inequality leads to a’contrédiction. If we had 
k < min(m,n) then k < mand k <n, so Jil: k < m,. (otherwise k >-m for each / 
would imply. k > @) “and 3i2: k < Ni. Now for 1 # max(il, 12) we . have 
k <m, $m and k ¢ Ay <n, so k < min(m,,n;) 2 Ki $k. The result k < k is a 
contradiction, which forces k ® ‘min(m,n). | 


We ew. proceed with the main body of the correctness proof for C. 
Consistency proof: In this part of the proof, we.,will use the abbreviation 
LSL to denote use of the Limit Size Lemme.’ If: we are given a complete 
execution sequence as in the statement of: the Thearem, wwe, Must show that if 
x = X> and y = y,, then ((x), (y)) € EXT¢.. This is true, if and only if 

#y = #x and y[i] = y xL§] we = y 


- jet, 
so we shall verify both a size Property and an. ‘element property of y,,. By 


the input suspension Property . of an execution . Sequence, > X%;.* Xo 3X for all J, 
so we must also have Xo 5 x, In particular, IK ox, Now we have 
#¥0 = sup{ty;} (LSL) 
= sup{#s.2} (by EXTp) 
2 #s, (LSL) 
= sup{#s,}  (LSL) 
= sup{min(#x,*, #r2)} (by EXT). ee 
= min(sup{#x,*}, sup{#r*}) (by the Minimum Limit evenak 
= MIN(#X—, #7.)  (LSL). . 
If #X%» $ #0, then we have #y, = x, 8 aX, which’ ‘is the desired size 
” property. Otherwise, (*) #r, s io ‘and we have - ae we 
ty. = #,, : 
= sup{#r;} (LSL) 
= sup{1+#s,*} (by EXTp) 
21 + sup{ss,*} 
= 1+ #8, (LSL) 
= 1 + min(#x,, #7.) (from the. previous Fhe of paneer 
= 1+ #r, (by (*)), . 
which can only be the case if #y, = We * “ But (*) yields © = #F, < *x,.. 


- 98 - 


so. #X, 2 0, This forces. #y,:2 #X, ® ©; which .yields the desined” size 
. Property in this case as well. = 


‘The siement ‘condition is CERNE Ware te establish. We ‘need to 
‘show that . 
yak] = xa S1. VK $ He ee 


jel 
Now for any k < #y,,, the corollary to LSL ee Ji: k < #y,2, Since 


y® PREFIX y. and: y? PREFIX y,, ‘We have YoCk] = y*{k} # yk]. 
We can now work with the particular dan) sate i ragweed hed 1, We have: 
yk] = 6°fk] - Gy EXTy)- ere 8 Big 5 <8 

* 6{k] — (since 6," PREFIX s/) 

«AC kK} + ATK) (by EXT, 

K[k] + r{k]  (sisice r* PREFIX FH” 

xk] + (088,°Mk]-. (By EXT), 

x[k] + (Oey Mk] (by EXTp) 

“Rolk] ¥ “(oey)Tk) “(since XqeX;). 

Thus we have y{'k] * Xof kT + (ooy, TK}, ‘which ‘yields the pair’ of equalities 
(1) 7 y fT] = xl and” 
(2) Vk>1: yk] = X[k] + yk. 

We ‘now claim by induction that for all k <$ Wis al 


thane , 


yk] ® y Xj. 


The basis step is precisely | gimee: (1 ; above, and the induction | step follows 
directly: by: 5 ou me ‘ as BS ade 


yk] © xoCk] + y{k-1] = Xk] + e old] * x xo J]. 
| al 


in which the second equality. is. the, inductive hypothesis and follows from 


equation (2) above. But this now gives us the result 
k 


Yolk] = yk] = D7 Xo 5], 
which is precisely the required element condition. This completes the 


consistency portion of the correctness proof for C. 
Note that the inductive argumerit was necessitated ‘by the cyclic structure of 


the system C. In. general, a cyclic system requires induction. of some ferm.in 


--order to establish that its external characteristic relation’ is satisfied by a 


-.complete execution sequence. 


For the synthesis portion of the proof, we need to. construct an 
- appropriate execution sequence for the system Cc given an input stream x and 
an output stream ye The sequences ‘we construct nee shall repeat in periods 


of four states, as we now show. 


Synthesis proof: Given streams x and y for which ((x), (y}) € EXTc, we 
must realize the internal behavior of the system C by an appropriate 
execution sequence. Let k=#x (note that k may be infinite), and let "@" 
denote the. stream concatenation operator. . We proceed.‘to ‘construct’ an 
execution sequence §$p,...,$;,... in which each system: State. 4 is a 4-tuple 
(x), 8}, Tj» Y;) of dotted channel states. 
For each natural number / starting from zero, define 

(0) Sq = OC LsijexCi+lsk], yldsile, (O@y)C1:4)-yLij, yld:i]+). 
~ For. iz0, this reduces to the case of the initial system state 
$= (x, +, ° 0), ). 
“For each natural number / starting from. one, define 
(1) $4.3 * (x[1: t-1)>xCizk], y[isi- -1)}+,, (0@y C1: i]s, yClsi-1Je), 
(2) Sai2 3 (xC1: 1J]>x[iel:k], y[i: i- “ls “Li ], (0@y)[1: ij-, y{l:i-lJ-), and 
(3) Say = OCLADxEeL sk), YOLt)s, (Oey HET AYE yETst-T)-yliD. 


The above formulas (0), (1), (2) and (3) define an infinite sequence of 
system states So)... »$),... for which it is again both. tedious and straightforward 
to verify that it is in fact a complete execution sequence ‘for the system C. 
As before, the gory details are omitted here. 

We now make some observations about the sequence that we just 
‘constructed: It is cyclic of period fotir and corresponds to a particular order 
of system actions. In the states given by formula (1), a packet has just been 


absorbed by the A module from the R thannel. The states’ given by (2) 
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correspond to module: A: processing .a packet.from, input channel. X, In. these 
States, the value of this input packet is added. to..the: packet. recently taken 
from R and the sum is seen as a ; ewiy Sonereet packet on channel S (not. 
i yet a acknowledged!) denoted: by the “ytkD In the States, given by (3), 
a inedule D has absorbed a “packet pene channel s, and this packet is newly 
Sane 3 in the states for the channels R = Y The states given by ( 0) 
reflect packets output by the system C saving teen: acknowledged by the 


PT ee 


., outside world. i oe ; ; ete teat 


If the size k of the fapuhs. stream. 48 finite, then. the. ‘above 

_ sequence of osystam: states’ will see ouneen after Sais AY’ states’ from 
this point on wil be equal to the limit state oo : : s es a 
Oia yen OER Ye Oo 

in which. all the input packets: ‘Nave: been’ processed. and a y complete response 

has been passed to the outside world. - Since the sequence of states is 

eventually constant in this: case; the: limit is’ ‘precisely’ ‘this Tepeating terminal 

State, In the Case of an’ infinite input stream x, ‘the. states in “the, infinite 

sequence are al distinct, and . this terminel ‘sate. is: the. lipait- evew thaugh it 


does not actually oecur within the sequence, | - 
This completes the correctness proof for the system, C. 
6.4. Proof for a nondeterminate geratent 
_ The corvevinets proofs given in the two. preceding sections heve 


dealt with modules and systems that. are explicitly determinate, Our 


_ techniques, though, have been designed to handle: nondeterminate behavior. 
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This section contains a correctness proof for the sample nondeterminate system 


S depicted in figure 5.4-1, 


_ System S 7. 

inputs X( integer) 

outputa Yidatager )- 

internals U( integer), V( integer) 
Submodu les 

“J 4nputs X, VE “outputs U 

F inputs U;. outputs Vv, Y¥ 
Initially empty: 


Figure 5.4-1: A sample nondeterminate system S 


This system, whose behavior was discussed in the last ‘chapter, is composed 
from. the nondeterminate: merge module J: ana the feedback modified first 
module F, both of which were- described in: section 3:3. ‘ The nondeterminacy 
in the system's: behavior arises from: module J. passing on its output channel U 
an arbitrarily chosen interleaving of the Packet streams taken from the two 


input channels X and V. 


We can informally characterize the behavior of system s in Fesponse 
to an ‘arbitrary input stream X. If there ; are no ‘api on channel X, then 
nothing can be done, and the empty. stream is output on channel Y. 
Otherwise the first input vatiie is taken by: module I and eventually passed 
on channel U. This packet is output. on Y, and a packet with value four 
greater than the given value is sent on V back to module J, where there is a 
“pace” between it: and the second input packet. If it wins the race (gets 
processed and output by J first), then it: is output ‘on ‘*Y and ‘no further 


packets get sent out on V. If it loses, it finds itself in successive races with 


moves 
successive Anyot Packets from x util it finally wins wins, _ Thus, the, system S 
“outputs all of its input packets in the order in which 29 1 agp pReSABIed as 
input, but also outputs a packet with value four greater than the first input 
‘packet, This extra pecket may appear in the output at any Place after the 
first packet in the arom. : (Wie iow proceed to Prove, hat the sysjem S 


behaves precisely» = our informal specification msyaiathst” 


ifancodnt 


@ Tepeat, the, Aafinisions of the ca chatacteristic relations 


EXT, ¢ coe Sey x a), aad. EXT ¢ UU") x (V" x ¥*)) for the madules J 
and F. The relation EXT; is defined by a 


aig Jabs 5 att 3Y 


((u), (vy) @ EXT; ces y @ U and #v = Mrin(1, fu) aad er e uli] vi < wv. 
and. EXT, is defined by, 6) osc oie Sted oo aetutu ane oe eit 
ae hOGNn (a), « EXT, <9) ade amenge GE MiendoWicn (ff eat 
. Note that EXT, is satisfied, pracisgly when flsto#X sod wand Wand Vv dodwrias 
disjoint subsequences of U and together, cppsaln all the elementeimt ui ‘For the 
_ System $ as, avenge, wer bane, EXT 9. ((6") a De: andr dha, (We: EXT, velll 
hold if and only if beth x and y are empty or if Vo aac % wguaedo aura 


*"y = a + x and yl) = x1) neh Poe atic of x. and OL 144). 


“We now state the correctness theorem = fia realization of ms system S. . 


vis Meets isqiss TH ST 


sob $f sa Gaal 


“Thiorem: (90), (yD ie EXT, <89 (00, HF INT, &> 
<=> 4 _@. complete execution, sequence, {iS $x}. fork: smo’ that xi aw idad 
ate s y. where % and Yo are defined a eae Up, Yor. Yo) and 


* nt wy = Oe Us) Yor Yo) ere 


: a> gasd Yom tame x. dar? att mec? tare hs 
Ins an ecieilen Sequence forthe system:,§,..aystem states: are of the fetm 
“ ($,$,° ay where §. a = (%, Mig. Vie: Yi): ; and; $/..9: 2, ud, mA: yi). dou Bre: comy 


Saecbh GC 8 Ha TM Fhe ae Pe eo POLY 
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property that should be stated here is consistency: 


(0, v,8), (u)) € EXT, and ((u4), (vj, y))) € EXT forall 1. 


There are a few interesting properties relating to least upper bounds’ 
and execution sequences which we. Shall establish heforg (going into the actual 
details of the correctness proof. These results are contained in the following 


lemmas. 


‘The following lemma is called. the Sum. Limit; Lemma and asserts 
that the least upper bound of the termwise.sum of two sequences is the sum 
of the least upper bounds of these two sequences.. The Sum. Limit Lemma 
will be used in the consistency part of the - correctness: Breet foe ayia S$ in 
.the same way the Minimum Limit Lemma was. used inthe correctness proof 
for system C.in the preceding section. 


Lemma: Tf {x;}, {yi} are nondecreasing sequences of aatural numbers for 
‘which x = sup{x;} and y = sup{yi), and if we define the sequence {s,} by 
s, = x\+y; for each i, then sup{s,} = x+y, 


Proof: If 3kl Vidkl: x=x1, then x2x,,. If 3k2: Vidk2: YiEYu2s then Y2¥x2- If 
both of these hold, then for k = max{kI,k2)° We have 

1>k =D S| F X/+Y, = XetYy = Spy SO, 

SUP{S)} = Sq = XK+¥e = Xi*¥a2 = X+Y- 
‘Otherwise, {x,} and {y,} are not both eventually constant, so at least one of 
these two sequences must increase without.bound. If it is {x,} that is 
unbounded, tien xs, which gives us 
sup{s;} * sup{xi+y,} > sup(x,} 2X Zoe vety | = x+y, 

This completes the proof. , 


_ Before we get into the actual correctness proof for system $, there 
is one more preliminary result that needs tote established. Suppose a packet 


system is in a state for which all packets have already been acknowledged. _ 
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(In terms of “dot notation,” all -the..dets fer this: state will he. at the 
right-hand ead. of their streams.) ‘We would” tke t infée? from this that the 


system is in a limit state, 10. has finished its ultimate response to the 


19 rae : ari ay 


* presented input. In other. works 
 PLemima?— tt $; = 3! in an execution sequence (Xt, sh) for « a + given system, 
then 89 S85 Soe mp (aM 
Unfortunately, this is not always true.. There are circumstances cedar, which 
‘the notion of “ultigiste: response ‘is nb¢-well @efined.: Consider &' module with 
‘one. impast channel aad one output hatinel? and suppose that if it’ is ‘presented 
the input stream 4a), then either “of the ‘two oaépit streams’ (8) or | (b;'c) 
‘constitutes a: valid respotioe, If-Ghe méBulecoutpate a packdt with “Watue b, 
then it. mey.cbe considered at Having fully resgenidd -to a irput packét''a. 
But it cannot be determined whether. ¢f netithe°patket ¢- wilt come dut 
subsequently, so:thete t-wei way to wil: ‘when the “tebdute ‘has yielded its 
‘ultitnate ‘output, Le. finished responding to. its input. mis. ‘kind of anomaly 
occurs if a module allows two distinct ultimate Output  Tespanaps ec some 
given input ‘stice, and one. of. these ovtpud: slices ds, @. ptefixoaf othe: othetsoIf 
we can rule out suck situations, then “the ‘condftion stated above will be 
‘Satisfied. — Accordingly, we define a “module to 2, to, be. strict Af. its. behamtor 
prohibits. -Qne ;outpat slide from: dejng apoefix of wee ap tnere 4 rietty 
input slice to which the two given output ‘aitbes are e distinct, valid ‘Fesponses. 
Formally, we have i ae oa 

finkion: A modele M is striet if whenever we Rave (Sin; Sion) € EXTy 
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All determinate modules are obviously strict, and. any module for which the 
sizes of the output streams are functionally determined fromthe inputs will 
also be strict, This includes the nondeterminate merge module J. We now 
state the corrected lemma, i | 

Lemma: If all modules in system SYS are’ strict, and if $= $° in an 


execution sequence {($;, $,°)} for SYS, then $, = $4'= $, = pe {$;*}. 


Proof: For any possible system state ($).1, $,,° ) that can follow the ‘given 
state j, we must have $ PREFIX $,,,¢ prera $= $#, which forces 


(1) $3 = $;. reg . 
Also, $, = $" PREFIX $,.:° PREFIX $;,,, 50 
(2) $; PREFIX $,,); 


Now equation (1) implies that for each module M in the system, its input 
‘Slice remains “unchanged ‘between State j vand state Utd. _ Equation ( 2). implies 
that M's output slite at state j is a prefix. of, M's output slice at state jel. 
But M is strict, so its output slices at these two states must be equal. ‘Since 
this holds for all modules in the ‘system ‘simultaneously, we must have 
$= $,). ‘Thus no successor state to { may differ from. it, 50 the state at J 
must be a limit state. This establishes the desired result, . 


We call the above lemma the Cutoff Lemma because it “cuts off” an execution 
sequence once all packets are acknowledged... 

We now proceed with the main body of the correctness proof for 
the system S. We must prove that the external relation EXT, coincides with 


the internal velation INTs. The proof divides into the two usual portions. 


Consistency proof: Given a complete execution sequence. {$i $;°)} for S, let 
oar Xp and y zy,. To show ((x), (y)). € EXTs, ‘here are two. cases to 
consider. If xe, then the . initial _ State must be given by 
(Kg. Ups Vor Yo) = (esesey2), 50 by the Cutoff Lemma We, have Ya =.Yo = € 
“Thus EXT, is always satisfied in this case. Otherwise #x > 1, and we have 
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his following chain of dimers for the size condition: _ 
#y,, = sup{#y,} (LSL) og ET . 
= sup(4u2} (by EXT») 
= My (LSL) = . 
= sup{#u}  (LSL) 
= sup{#x,? + #v2} (by EXT) 
-. 3 sup{#x,2}. + supfey, oo {by ne See: Limit. lemma) : 
8 AK AVG: (LSE). 3 
Now we also have ae 
av sup{#v,} (LSL) . 
= sup{min(1,#u,8)} (by EXT) 
= min(1,sup{#u*}) (by the Mingnum Limit Lemma). 
= min(1,#u,)  (ZSL). 
Now by EXT, #Up = #% +, #¥p = Ay + 0 > 0, TRUS Ma 2 #Ho 2. to, 50 Vy = 1 
‘and #y = 1 + #x, which is the required size condition. sia 
‘To ‘establish ihe element condition, we must show that fl }* " x{L1a and y. iss 
“merge_ of x ‘and C164), We first note that y 9° s¢ (oy the. initial state 
property) and Vo r € ‘(as proved above), * there mnt be, a state F for which 
vio = € ‘and Visio a é. Now by the ‘connection property, . Vier? PREFIX Vis SO 
Vv, « €, which by EXT, implies ue “a €, ‘But by EXT, as long | as va =z € we 
have u, = x," PREFIX x. Then since u® « € and u,* PREFIX u, we must have 
u?C1) = uli] = x[1]. Now for any n 2 i, ue PREFIX u,? $0 UnC1] = 2 + X15 


pr 


thus, by ae “EXT, again we ( obtain yot iT = Puptttd = xE1}. Since this holds 
for all n > i, we must have y,[l] = x£€ik- BAB Mabe a. 
What is. left to show is that y, is a merge of x and (x[1]+4). We have 
already shown that there is a state i for which u;*r ij* x{ I]. “Then by EXT; 
we have, V;,,# xt 1.J+4).. .Now. by completenass -of the seoecution - sequence there 
must be a State J for which x; _SUBSEQ x;* and N; ‘SUBSEQ. vie . _ Since 
x)" PREFIX x 2X8 x, and since ia < #v,, 8 1 for all. “J, this means that for 
fhe J we just chose we must have X #® x@ and Vv, ® vi 3 OC J+4), But now 
by EXT), U; must be a “merge ‘of xe and yale which. ‘means u is a’ “merge ‘of x 
“and Va = (x[1]+4). Now we use the ‘completeness’ property again: given J. 
there must be a state k for which U, SUBSEQ u,#. By “EXT, Ye U3 and by 
another use of ‘Completeness there is a state m such” that Ye ‘SUBSEQ Yu" . “But 
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then y,," PREFIX y,,, and by tracing a transitive chain of subsequences and 
prefixes we obtain u; SUBSEQ y, SUBSEQ y,,, Finally, since x ( and («E1J+4) occur 
in u, as disjoint subsequences, they must. occur, in Yoo ay. disjoint subsequences. 
But X = xX, and (x[]]+4) = v, Tepresent all the packets that. can ultimately be 
passed on channels X and V, sO all the. packets that can ultimately be passed 
on channel U are contained in U,. ‘Similarly, all the packets that ca 
ultimately be passed - on channel Y are contained. in Vee Thus y is a merge of 
x and x01 }+4), satisfying EXTs, which completes ithe consistency portion of 
the proof, 


The element ‘condition was } extremely acu to verify, because we 
nee. to go tracing the progress. of individual, ‘packets. through. ie system. 
There seems to be no readily available method to simplify this proof, despite 


the elementary system structure, 


For the synthesis part of the ‘proof, if the systern's input and output 
streams are nontrivial, then the execution sequences will repeat in periods of 


. three states. The construction is. now given. : 


Synthesis proof: Given ((x),-(y)) « EXTs, we’ must: censtruct a complete 
execution sequence to realize this behavior: ofS internalty. The execution 
Sequence will be of the form $p,...,$)... in,.which each system state 3, is a 
4-tuple (x;, Uj, Vj, y;) Of dotted channel states. If. x = €; then we, must have 
y = €, and the required execution sequence.will Rave, all states identical to 
(+, +, +, ©). Otherwise, #x will be some k>0 (we allow the possibility of 
kee), In this case, y must be of size #y = kel, There must also be some 
finite index m such that 1<m< k+l and _ytal-* x({1]+4... Moreover, the 
concatenation of the remaining elements of y must satisfy 
yf l:m-1]-@ yEmelikel] = x, 

which means that | 

. y = x[l:m-1] @ x[1]+4 @ oxLn: klk 
(We are abusing notation here to let "@" concatenate packets with teams): 
We now construct our execution sequence for x and y. The streaii Vv ‘is 
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defined ‘by’ vos (1J44), 
“For each natural number i from zero through n-1 inclusive, define 
(A0)' Bay OCLs F]exeiedsk)], xC1: i]e, evE1idd, xf: 4D). 
wher 180, this 5 réittices to ‘the case of the initial system, state ape 
| HECK : 
For each natufal number i from one through m-1 inclusive, define ; 
(A1) Sain * (ELF ]oxf i42: k}, x[1:i- “1}-xCil, evel: 4], XL: As 1] ») and. 
(AB) $3.) © OE1: iJ>x[ 141: tk], x{lii}e, «VEL: J, xClii- “1x17. 
We now define the specific system states 
(B1) S3_.q ® (XL Lim-1Joxtmik], xClime1 Jv 1], vE1]+, XC Lime1]-), 
(B2) $50.1 = (x[1: m-1]-x{m: kJ, x{l:m-1]@v[1]>, VE1}>, 1: m-1}>v{1]), and 
(BO) Sai--@ (xCl ime 1}xfaik], xTim-1 fever, Voy, xt: s-1J0vE1}- ue : 
_ Finally, fog. each natural number: 1 2 m+], define 2. rs 
(C1) Sg.o = OLdsi-lJexCisk], x[1: :m-1 Jov[.1JexC mz A-2}xL- A). vO), 
x[ l:m-1J@v[1J@x[m: i-2]+), 
(C2) $34.1 = (mE 1p 4-1 ]oxf irk], xC1im-] Jovi Jextastel]>, MOL Is,, 
a - XE L:m=1JOvE1 JexEm: i-2]-x{i-1), and 
(CO) $3, # GCL1s4-1) 81K), xLTime 1 OVE 1 Toxine 11+, vel}. 
x[ Lime Jove Lois bet je}? © 
When i > k+l, formula (CO) generates the system state 
. $y = (x, xC1 imo] JovGLJextmsk)e, is aa aa kJ de: 
which is a Hmit.state for system. S. 


The above set of formufes generates a well-derined infinite sequence of 
system | states $>,...,8;,... for whieh it 13 6nce “again Unenlightentitg to Werity 
‘that it {8 a complete execution ——— for >, 

The. foermules.we have just eva rere some corament in order to 
be property uaderstool. The execution sequence constructed above consists of 
three parts (A), (B) par (c). Part (a) corresponds oa the first act packets 
from X being passed through the system and out on Y. In ene: ' states ‘given’ ty 
formula (Al ), module id has received a packet from x and is passing it out on 
channel U. In the. states given: by. formula: (42), modute F has absorbed this 
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“packet and is passing it out on channel Y. For the firt packet F ‘receives, it 
“also sends out on channel V the alae of ‘this packet incremented ry 4. The 
states given by (A0) correspond to the outside would 4 yeciving an output 
packet and acknowledging it. Part (B) handles the ‘processitig “of the one 
packet passed on chaanel-V. In state (B1}, this packet is absorbed by J and 
. passed on U; in state (B2), it is received’ by F aid’ passed’ out ‘on Y; and in 
‘state (BO), it is received and acknowledged’ by the outside world. Part (C) 
treats the processing of the: remaining inpat packets from’ the m-th on; the 
states. given by fermulas:{C1),’ (C2) ‘and- (C8): torrespdnd ‘respectively to ‘those 
given by: (Al), (A2}-and (AO). - 


The proof of correctness for the. nondeterminate vem S is now 
: : : Da DD eae 
‘complete. We shall talk ‘about more " ganaral, proof techniques in the next 


section. 


6.6. Proving correctness of more complex packet systems 


So far in this chapter, “we have given correctness proofs for three 
particular packet systems. Ah three systems are rather simple in both 
behavior and structure, but a lot of machinery has to be manipulated in order 
to verify them. There is a significant problem that. arises in considering how 
to apply the techniques that have been developed here to larger, more useful 
systems. As systems increase in coltiplexity, their’ formal descriptions and 
correctness Proofs grow more complex. ata much faster rate. Proving the 
correctness of packet systems that are substantially larger than, the toy~sized 


ones we treated may. thus turn out so cone #., to be. of dubious 
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practicality, The euly eaeied for this nee woe situation is to somehow reduce 
the complexity of packet a hatied as they are seen from within correctness 


Sieate. We now addiees this issue, 


Much of the. complexity in. our correctness. proofs comes from 
setting . ‘up. execution. sequences... However, Jexeeution . seyuences: - were 
introduced into our model to -handle one particular characteristic of system 
structure, which. is cyclic interconnection dependencies... When a ‘systein's 
Structure is acyclic, its internal specifications may be characterized nruch more 
simply than through execution. sequences. , We ‘shall prove: that the internal 
characteristic relation of an acyclic system may de sealized as an. appropriate 
pune one or relational npeee of ms external characteristic. relations of 
the component ‘modules, Consider, for example, the System, SYS. Allustrated in 


‘figure $61, 


1 ‘ ( 
i] t 
wit ) 1 oy 


eee ee 


Figure 5.5-1: An acyclic packet system. 


Suppose that the exterfial specifications for the. ‘modules x 5 and. C are given 
by the respective characteristic relations EXT,, EXT and Xtc. “Let us also 


assume that the module A ts "determinate, ‘which ‘makes the relation EXT, 
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functional over ((W*) x (P* x Q*)), Then there are "two stream functions, 
ap: W* » P* and ag: W* + Q*, which together characterize ‘the behavior of 
module A. The internal characteristic relation INT SYS "for system sys is given. 
by the composition ca 

(Wi), (¥2)) © INTsys <8> ats ((xaq(W)), (ray) < : EXTe & tap) F), (y)) € EXTs. 
This compositional characterization relieves. us of the ‘need ‘to 0 ante the 


complications of execution sequences with the acyelie system sys. 


We can give a general formulation, of how the internal 
specifications of any acyclic packet system can - be characterized as an 
: appropriate composition of the erretnar characteristic relations. of the 


component modules. our formulation we one condition on is the external 
. MEQ: af 
characteristic relations of the component ‘modules must all ‘be. continuous. 


‘Continuity was defined in the preceding chapter, 7 "The formulation is 


contained in the statement of the following theorems. 


Theorem: If an acyclic system SYS has the structural description 


System SYS - ars 
Inputs “Whew=), 1.6, X(eeey 
outputs Y¥(---), ..., Z(---) 
internals U(---), ...,- ¥l-5=) 
Submodules 
M inputs P, ..., Q; outputs R, ..., S$ 


Initially UCu0>, «2.6, WKvOd,- VWeyOds: .2., ZCz0>, 
and if for each component module M the external characteristic relation EXT 
is continuows, then 

(Wp), Yorn) -€ INTsyg <#> 3 Up.yY WM ((p,. 9), ie 8) € EXT y, 
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One has to examine the Statement of the thearem carefully in order 
oe observe that it in esa characterizes INT sys. as a.composition of the. external 
characteristic relations Ty : 2 The crucial point is. “the existential 
quantification of the channel streams U,.,V through which, the EXT,. relations 
are composed. Proving the ‘theorem requires two directiona,of argument, The 
“left to right" implication asserts that given. a complete execution sequence 
realizing an instances of the vehavior of SYS,. there are appropriate, internal 
channel streams adécine the input to the output in a manner satisfying all 
the EXT. relations. This “will be Proved by using the Limit Existence 
Theorem and the continuity of the EXT y. . Note that this part of the proof 


does not use the assumption that the syttem structure is acyclic, 


sae . 


The reverse implication — that t anything realized as the iven. composition 
of the EXTy must also be realized vy a complete execution sequence for S¥S. 
This direction of proof is more difficult, and we need three preliminary 
lemmas in order to prove it. Lass 1 is a simple property of insertion 
mappings that realize streams as subsequences oft other. ‘streams. Lemma 2 
asserts that a subsequence relation between streams is unaffected by the 
presence or absence of certain packets. in the siveanisy Lemma 3 asserts that 
in producing execution sequences for the proof of the theorem, one can 
always find a sequence of acknowledged prelines so am to assure completeness. 


We now proceed with the lemmas and. the proof of the theorem. 


Lemma _1: If f is.any insertion, then f(i) > i for all i in the domain of f. 


Proof: The result is obviously true for i # 1. Inductively, if we assume. it 
true for i = m, then we have f(m+]) > f(m) > m, which implies f(m+1) > mi. 


é 
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Lemma 2: If x SUBSEQy and if ‘there is a m< #x such that 
MLl:m-1] = y[l:m-1] | and x[{m] = y[m], then x SUBSEQ y', | where 
y' = yCt:m-1)} @ y([melity). . . 


Proof: For any insertion f of x into y, define the function g by | 

g(i) = if 1 <m then { else Fi), 
& is an insertion of x into y which is the identity mapping over. the first m-1 
values, By Lemma 1, gm). 2, but ytm). a xEm] rules out g(m) =m. We thus 
- have doth a(m-1) = m=] and g(m) >m, which imply that. mis not in the range 
of & This fact, together with the fact ‘that yli] = y'li- 1) Vim, makes the 
function h defined by 

h(4) eif i <a then g(i) ‘aise oe =] 

an insertion of x into Y which proves. the lemma. . 


Lemma_3; If .{¢;}:is a sequence of streams. such that Vi: ¢, SUBSEQ ¢,,,, and’ if 
= ; sup {C\} is uniquely defined, then there is a sequence {c,*}.-of streams 


such that Wi: ¢;9 PREFIX ¢, and Wi: c° PREFIX’c,," and sup (#c,°} = #c. 


Proof: For each / we shall let ¢* be the longest. prefix of ¢; that is also a 
prefix of all the ¢, folowing ¢, More precisely, lets 
m 3 Sup {n <$ Bi cfisal = ¢Chin) Vj>i} 
and «4° = ¢{l:m]. 
Clearly, {m}. is nondecreasing, so ¢,° PREFIX.¢,,,9 and.c?. PREFIX ¢, for all i. If . 
m= sup {m)} = sup{#c°}, we must show m =-#¢. Since it is clear that m < ae, 
this will be proved by contradiction; we shall assume m < #C and show that 
the sequence {C,} has another least upper; bound. under SUBSEQ besides C. 
If m< #c, then there is some i for which m =m and #c, >m. We 
shall claim that the existence of this i forces the existence of a stream C'«C 
such that c’ SUBSEQ ¢ and VJ: c, SUBSEQ Cc’, coptradicting the. unique definition 
of c = sou, {¢,}. First.observe that 
(1) 6 fl: ma} = Clim] (V5,k>4). = ofl: mj. 
Now take any pi; since ¢, SUBSEQ c,. (by. -tranaitivity of SUBSEQ) we have 
#C, > #0, > m. We first claim that 
(2) | - Gj L:m] PREFIX c, _ 
If this is mot true, then there must be some a<¢m for which 
c[l:n-1] = c{1:n-1] and ¢{n}c[n]. But then Lemma 2 implies. that 
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cc SUBSEQ c” where c= c{lin- “lJ @ ctnel; éc)... -Siype the . value; Of. Pe is 
7 independent of. our, choice of it (by equation (1). this. makes g an. upper 
“pound for all the ¢, beyond c, under SUBSEQ, and hanog, for aH; the ¢ But 
c' # ¢ and c' SUBSEQ ¢, which makes ¢' a lesser upper pound than c, giving us 
the desired contradiétion, ‘This ‘estabiisnes’ ‘equation ay GEA GREYS 

There are now 106 cases to odndider. | te (mel) * c{m+1], then 
- since equation’ (2) tmpiies: itt] w cee ay: ‘We ban apply Leiniia ‘2 to obtain 
¢; SUBSEQ c', Whére’c' ® ef 1:ay 8 ‘cL rie2: recy, “ptherwisé cimel fs ® “elavl dy, ‘and 
“since m+1°> a i, ‘there must exist a k > J (6k Which’ GEmel] « ” ‘etmel 3. But 
“eC 1s) = Gf lim} = cCl:m], so as th the first cdbe ia have SuaSEQ © 
The transitivity of SUBSEQ then yields Veer ee 

: G, SUBSEQ’ ot " SuBSEQ B.? 
In either case we must have ¢; “susstg' Which makes ¢ an upper bound for 
all the ¢,  umiler SUBSEQ:. ; ‘Butic’ SUBSEQ: Co whieh again ‘piaiudes the desired 
contradiction, © Thes. at is. impassiblel: ta-have Pop 50: We: must have 


m = sup {#c°} = We, “This completes, the prof. 


Proof. of. the- theorem: (=>)2 Tn “this half of! the’ prodt, wedo “not isd: ‘the 
assumption that SYS is acyclic. Suppose (Ow,ukKE 22 © INFayg. * This tHedhs 
there is a complete execution sequerice for SYS ‘reatiéing the slice Ore = as an 

ultimate output response to the input. elice tw,....x). | Pas 
If the execution sequeace: is given as £685 OPY, Aiton: the ‘limit’ state 
_is given by (®,, 8), where $,"= A GPA}. The limit Gifce $. WHE have 
the form (Wei Xr UssreiMeor Yor Zak Wei chitm tatt,,..vi tate the désited 
.v for which: hall ‘the: ga pere esa — ee vétations 

pa satisfied, = a SH oe 

Fer each module M with input ‘chanziefs” Pa bear! ‘Sat charinéls 


R,...,5, the following ‘three’ properties are true for alt 9 
(1) (p82) PREFINAB, MEE 
(2) (Fjs.0+,9))' SUBSEQ (AiyiaesBiei De! ‘and: | 
C3) iY (ric © EXE 

Applying the Limit Existence Theorem to théss slices; we hive 
(4) (p,... alte * Cp. G°)}, and 
(6) © (rc) = sup {€,,...,89) isthe unique 1.u.b., . 


"80 by continuity of M we have io. al hai € EXT,,,' ‘witch’ ‘ds the desired 
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result. 


Proof of the t eorem (ce) “suppose we are ‘given a stream for each channel 
of SYS such that the external characteristic relation EXT, of each module M is 
satisfied. : We need to construct an appropriate complete execution ‘sequence 
for SYS. If SYS has acyclic structure, then we may order its channels 
Cl,...,Cn so that if there is a path from. Cl to C2 through the system, then 
Cl must come before C2 in the ordering. For each channel C in turn, taken 
according to this ordering, we must construct a sequence {(C;,C; 4)} of channel 
states such that the limit state for C is c ©), where c is the given stream for 
Cc. 

Each channel C is either a system input channel or else there is a 
module M for which C is an output channel. In the former case, we define 
(6,,c,4) = c,: c{1:1]), where ¢ is the given stream for channel C. From this, 
must follow that oun, {ene = (¢,¢). In the datter case, all the input 
channels of module M have already had appropriate channel sequences 
constructed, so we already have a sequence of acknowledged prefixes of input 
Slices for M, ordered by the PREFIX relation and with a-unique l.u.b. under 
PREFIX. Since the given stream c for channel ¢ is related to this unique limit 
through EXTy, by continuity of M. there exists a sequence {¢} of channel 
streams for C such that ¢, SUBSEQ ¢,, for all { and such’ that ¢ = ote, {c,} is 
uniquely defined. ‘Moreover, EXT is satisfied at each state i, By Lemma 3, 
then, we sia define the sequence {C; Ay ‘such that for all i,. ¢,3 PREFIX ¢, and 
c° PREFIX ¢,,°, and such that sup {#¢,9} = #c.. Thus c = BP, {c*}, so in 
this case, too, we have oan. {(¢,,¢,)} = (c,c), | 

In this way. we construct for each channel a sequence of channel 
States for which the given channel stream is the limit. This. gives us a 
sequence of system States satisfying all the requirements for a complete 
execution sequence except two: the initial ‘state property and the connection 
property. . The. initial state property is..in:a sense trivial, since given any 
system SYS there is a corresponding system SYS' consisting of matching 
modules connected in the same way such that the behavior of SYS' is 
‘identical to that of SYS internally as well as “externally, and such that the 
_ initial state of SYS' is empty, with % = (¢,...,€). .SYS' is easy to describe: its 
"specifications are identical to those of SYS except for an empty initial state 


we AB = 


and for external characteristic relations defined by 
(Syne Smoot? € EXT y’ <*> Stour * Stout @ So and (Syn, Sous EXT y. | 
The comection property does net old tor’ the- sequence constructed 
above, since ¢,," is tet necessarily 2° prefix” of. ee However, we may 
interpolate 4 chanel state (76%) between %,c.°° aa eee! so that the 
connection property” is sucisfieds if we define ¢," = Gi amd ee = o* ‘then’ we 
Have ® PREFIN'G, — @* PREFIX g® PREFER ¢,,8, ° & $0886 c' “SUBSE Se. 
c2" PREFIX ¢ anid ¢,," PREFIN’G'. In this way, “the ‘required execution 
sequence is constructed by inserting “primed” systems. states ‘between each Pair 
of existing system. states. This ‘completes the proof. aie 


- With proper use of this theorem, we com greatly siniyhity correctness proofs, 
since acyclic packet systems may be specifies | and verified much more. ‘easily 
through the use of selationsl ond fuactomst qeaqposioion than by. weckhing 


ree 


iia ecards sare A ~ 


AY a 


The hierarchical stwuctaring of packet syqteme: abbows: us ‘te apply 
acyclic simplification. techniques even to verification of ‘Systems, wien directed 
cycles. Since a@ packet. system ‘'e an intgreempection, of cpmponent modules, 
any pottion of avsyutesiy may le iwell viewsd.as: a syatim. ‘Fie packer:system 
S$ shown in ‘figure 5.5-2 has a fairly complex’ structure, , including a directed 
cycle between modules F, G and H. We can grestly simplify. this. structure 
for proof purpeses by regarding. the, pen aS. eonsisung 6f ysodules A, B, 
C, D aiwé Eas a patieat system: ‘SI (tigate 88-3). “The epi “st ‘is acyclic 
and easy ta specify; its internal characteristic relation INT, Sis is an appropriate 
_ Composition. of the esternal.charavteristic: retations: for the modiales ad cha 
and E, But “the: principles, of packet commianication architecture allow us to 
treat system Sl as @ module whose oxtennat. charanteristic relation: EXToy,:is 


precisely INT,,.  TRus we can reduce the structure® of* system’'S' tobe ‘as 
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Figure 5.5-2: 


A more complex system structure. 
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Figure 5.53: 


Five modules forming a system $1 within S. 
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Simplified structure for system S. 


ce Figure. 5.5-4: 
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shown in figure 5.5-4. For the system S, our acyclic simplification technique 


has reduced the structural complexity by one-half. 


It is possible to carry our technique further by treating the portion 


of system S consisting of modules F, G and H as a system S2 (figure 5.5-5). 


Figure 5.5-5: A second system S2 within S. 


This manipulation simplifies the structure of system S enormously, reducing it 


to what is shown in figure 5.5-6. 


Figure 5.5-6: Further simplified structure for system S. 


This structure is acyclic and therefore simple to characterize. It may seem 


that we have reduced our proof to the point of triviality, but this is not the 
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case, The only way to ‘determine the specifications for the cyclic system S2 
i. through execution sequences; thus, the proof for system S has deen 
essentially reduced to a characterization and -eorrectiiéss proof for the new 
system $2. For a general system, structural pia aaa techniques such as 
these can greatly Bees the complexity of correctness proofs, but in the 


presence of directed cycles rere: still is no way to avoid the intricacies of 


execution sequences. 


We have just seen how the structure of a packet system can be 
simplified for proof purposes by “collapsing”. portions. of the system into 
modules. Using this technique together. with the theorem we proved about 
_ acyclic systems can greatly reduce the complexity of -packet system 


. verification. 


In this chapter, we have shown how: our’ model for specifying 
packet systems can be applied to proving them correct. There is no question 
that the correctness Proofs presented here are..complicated, even for small 
systems. _ However, part of the complexity found. .in - these proofs was 
contained in the development of a basic sat of, lemmas -that can serve. as 
building blocks for other ‘proofs. There are 5 number., of approaches to 
generalizing the proof techniques that have cen ouean tad: here, and we will 


describe some of them in the next chapter. 
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CHAPTER 6: CONCLUSIONS 


6.1. Review of the research 


The basic task of this research has been the development of a 
methodology for formally describing the behavior of packet communication 
systems. The work here was motivated by the notable difficulty of designing 
computer systems and, more specifically, in making sure that they act 
correctly. Consequently, one of the major goals underlying the specification 
techniques presented here has been suitability for formal verification of 
system correctness. We have taken a particular view of systems: hakdivare 
systems composed by interconnecting smaller units. The research presented 
here has been a first attempt to formally describe and verify the behavior of 


systems viewed in this way. 


The class of packet communication systems is distinguished by a 
number of desirable system structuring properties that facilitate description 
and verification. Our approach to specification depends on the properties of 
modularity, hierarchy, speed independence and uniformity of interface. Until 
now, the principal benefits under which packet systems have been promoted 
have concerned the fact that the asynchronous, concurrent operation of packet 
systems allows for faster system performance by allowing for. more efficient 
scheduling of the available computational cence This document has, for 
the first time, identified those properties of packet communication architecture 
which make packet systems well-structured and amenable to formal 


description. Appropriate use of the concepts of structured system design 
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makes it easier to design and. canbertada systems even. without formal 


verification; with formal methods, system Correctness can be mathematically 


demonstrated as well, 


Systems may be viewed externally, through . eoried interaction with 
the outside world, or internally, ‘in terms of their composition from smaller 
components, From an external point of view, ‘the beliawior of a neces system 
is the relationship between sequences of packets transmitted | on the system's 
_ input and output chantiels, The denotational approach we have taken towards 
external specifications for packet systems is elegant precisely because it gives 
direct mathematical ‘expression to thes sequeiices of packets; the formal 
descriptions that constitute our exterial ‘specifications contain no extraneous 
notions that would only serve to occitidé the relevant behavioral properties. 
Thus, the use of mathematical operations ‘on ‘streams provides an appropriate 
level of abstraction to aid in the formal description of 3 ft ayeiem behavior. 


Denotational specifications may be ‘provided for modules at all the 
hierarchical levels of abstraction in a | packet “system, ‘This gives a complete 
- formal description of the behavior of the system and all the component 
modules in it, from the top level down | to ‘the primitive ‘modules at the 
bottom. In order to verify the system, it mint be shown ms at each level 
the given iiéauiee are interconnected so as to perform the éortack function. 
Because of the great difficulties ‘involved _ “in ‘providing a denctational 
~ characterization for .the behavior of ‘an ‘larcoinection of nondeterminate 
modules, ‘in ‘operational approach to’ system verification was chosen, There is 


no existing methodology for formally describing compositions of either 


se Me A? 
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“hardware « - scetware ie degen Jet \ccarad verifying hep with the notion of 
erecation ‘Sequences, the behavior, of a system can. Raq expressed in terms of 

the behavioe of its component modules and the way they boc struguiryally 


fitted together. By handling determinate and ‘Rondaterminate systems in a 
uniform. ee the ‘esearch here constitutes « a "banal innovation ia the 


oe 


- field of system specification. 


Another advantage of our formulation. of .execution sequences :is, that 


OB; system 


they are built Up directly from sequences . 


channels, This basic notion is an, . iaumieaet for. deserhbing: the 


internal operation of packet systems, since if. matches the occumsences; that: are 
being modeled. Moreover, for, nondete: mingte behewtor,,.the, moment. at..witich 
a module decides which of sevgrql. alternative, actions fn, perform ie: captured 
by the way we have defined the notion, of a Prefixes, of channel 
s packet, are regarded as 
being made when the rene: er id Dh orseedadarertter All the notions 


eke 


embodied in execution sequences for packet systems have been savelorec in 


een rhe 


streams. Decisions based on the arrival of a particu 


Ps. 


‘fich a way as to be consistent with respect tothe physical properties, of the 


. “systems... ‘Thus, execution sequences as presented here oN only peracid system 
apf} artes 3 wk 


behavior and alow for ‘formal ‘verifiation, but. also “mupport appropriate 


Vvreote of 
Pear Bs Me ed 


conceptual abstractions. 


fee BE 


. In addition to the basic. davelopmgat, of our, 4 specifi 
have demonstrated its applicability to. verification dy, Adie Qut, cerzaginess 
proofs for three sample packet systems, fk. the | cour 


states and proved. ‘Rumper of auxiliary lemmgg,,..Some.of these, Jemmas, 


ew. _souuttonsiote 


& * dpuee nes 
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Sten ihectase! we have eerie a Fsctbotiar © meecripsive: formalism for 


. specifying the Amtaraction of pocket modules and sysems, with the outside 


world; we have formalized the concept of what tt _pueens tee a system, to be 


PES a, 


combed: from modules and how its operation my S detined in oe, = the 


wpe’ gis 


behavior of the component ‘modules, na we ) have begun he development of 


PED FR IgSGCs 
methods for formal verification of the correctness of packet systems. 
 sighog cmc 
6.2. Future work fie gees 


eye ae! tak cake ee 


The work hore has opened uP. the way! for . @  ergat deal of. further 
research into system meson and iaerlacaae Ricede are two principal 


areas open for future inventigation: the i use sof streams ‘and stream envent 
. eihe 2% Fad 
in external specifications, ad generalisation « of our r root techniques ‘0 more 


mfg peed? atte 


complex systems. eS 
eae There ae! no way to _Teduce_ _the _pomplexity of me. external 
characteristic relations of modules Within a packet, system, . but it. js feasible to 
: develop higher-level descriptive formalisms for freating . streams and . their 
7 operations. — Recall, for example, the adder | ,,module AY : which, adds 
corresponding packets: from its Anput. channels x and R to. yield. the packets for 


_ its behavior. by. the’ Feletion EXT, 


ESTES! 


its output channel) S. We characteris 


cettnes by - 

(Or), (8)) « : EXT, <=> w s + mine and “17 s oy + rEAD vi ‘ rs 
at a higher level, we should be able to view the relation | asa functional 
operation on streams, expressed as 8 = x +r. Of course, in order to use such 
higher-level descriptions | ‘profitably in proofs, we ‘would need to cevelce a 


methodology for performing various manipulations on them. — with’ such a 
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methodology, it seems that correctness proofs can bs ‘further one by 
bringing the level of formal description closer to our "conceptual view of 


packet ‘systems and their operation. 


There is even more room for further : fesearch in studying the 
development of a general proof methodology . for verifying packet systems, 
Given a particular packet lia it is a lengthy exercise to work out the 
details of a correctness proof, but a eandral Brook methotology would: yield a 
systematic approach to the art of proof ‘generation. We now discuss some of 


the issues involved in abstracting the correctness proofs we i abvined:. 


All of our correctness as procte have both a consistency part and a 
synthesis part. The consistency part is set up to show that for a given 
execution sequence, the aystem input. aed output ; slices satisfy the external 
specifications for the ee Since the external specifications are given in 
terms of streams, the consistency part consists of showing. that various streams 
satisfy desired properties. For our proofs, these properties relate to the size 
and elements of the streams. Accordingly, _ _ the consistency portion of a 
. correctness proof is often divided into two parts: ; a size condition. and) an 
element condition. The aynthiesis portion of a correctness, Proof entails the 
construction of execution sequences to realize oven ie dameast penavecs: These 


two parts, consistency and ee compose the framework of a porrectness 


— for any packet system. 


In order to produce a correctness Proof for. the. genexal case of an 
arbitrary packet system, one must develop a set of tools for handling the parts 


of a proof mentioned above. We now discuss each of these parts in detail. 
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For the ‘consistency portion of a correctness proof, we need to 
establish chains of equalities connecting the various system idan and output 
streams. Construction of such chains, of course, is accomplished through the 
use of the external specifications of the component modules of the system. 
With all but the most trivial of systems, separate ‘chains must sd set up to 


handle the size and element properties of the channel streams, 


Tn our proots of the systems c and S, we made use of special limit 
lemmas to complete the size chains, The Sum. Limit Lemma, for example, 
asserted that the limit of a ‘termwise sum of two ‘streams is. the sum of the 
limits of the two streams. Mathematically speaking, we may view this 
‘lemma as stipulating that sums and limits. “commute” | under appropriate 
"conditions. | “Such 3 a commutativity property essentially states that the termwise 
stream ‘sum operation ‘is continuous in a certain mathematical sense. For an 
arbittary packet systeni in general, continuity lemmas such : as hese are needed 
in ortfer ‘to establish ‘relations among ‘streams ia: a system's limit state from 
corresponding ‘relations that hold for intermediate wakes, A fairly large class — 
of arfthmetic and logical operations satisfy the desired continuity properties. 
It’ may be wise to restrict the class of packet systems to “include a those 


betiiVidrs fot which the size properties are continuous. 


There is an | entirely different conceptual abstraction associated. with 
the element. properties in a Saigisiahey proof, In order to relate particular 
output packet values with corresponding input DEGREE values, it is in general 
“mecessary to trace the passage “of” ‘individual ‘packets through the internal 
channels’ of ‘the system. This becomes a difficult task even with relatively 
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simple systems ach as S, since the transmission and acknowledgment of a 
packet are traced through an entire series of applications of the system's 
connection properties and the specifications of the component modules. In 
order to obtain a general proof methodology, it is essential to develop some 
formalism for describing and deriving properties of the packet transmission 
pathways within a system. In the system C, for example (see figure 5.3-1), 
we should be able to formally state that any packet received on channel X 
will be passed through module A onto channel S$ and then through module D 
onto both channels R and Y. By a judicious use of appropriate descriptive 
tools, a high-level formalism for manipulating properties such as these should 


be achievable. 


There is another approach we may take towards consistency proofs. 
In the characterization theorem for acyclic systems given in the preceding 
chapter, one direction of proof did not require that the systems be acyclic. 
We proved that in any complete execution sequence for any packet system, 
cyclic as well as acyclic, if the external characteristic relations for all the 
modules are continuous, then the system's limit state satisfies all these 
external relations simultaneously. It may seem that this result would make 
consistency proofs almost trivial, but ccntinuity must be established in order 
to use it, This alternative approach, although it does not reduce the 
complexity of consistency proofs, may be more suitable for developing 4a 
generalized proof methodology than the ad hoc approach used in proving the 


three sample systems. 
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For the synthesis portion of a correctness proof, there is an approach 
to proof methodology that follows as a logical éuigrowth of the conceptual 
Notions available to the system designer. It is the designer's task to realize 
certain desired behavior through interconnections of various modules, which 
means that the designer must envision how packets are to be routed through 
the system in order to achieve the intended actions, The designer really goes 
through a conceptual simulation process of the system's behavior. The logical 
framework for a synthesis proof is thus already present as one of the 
elements of the system design process, Again, for a general proof 
methodology, one would need to develop some formalism for describing 
sequences of routings of packets through the various modules in a system. In 
the particular proofs we presented, there was a regular, cyclic structure to 
these routings. It is reasonable to expect that a similar regularity be present 
in the internal behavior of more complex systems. Exploiting this regularity 
should turn out to be helpful in constructing synthesis proofs for packet 


systems. 


As we mentioned in the preceding section, the lemmas we developed 
for our three sample proofs are suitable for use as more general tools. 
Another area for future research is a determination of the scope of their 
applicability and the development of a more comprehensive set of tools for 


system verification. 


In general, the study of specification and proof methodologies for 
packet systems (and perhaps other kinds of structured systems as well) appears 


to be a fertile area for additional exploration. The current research is really 
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only a first attack on the problem of formal description and verification of 
systems, but the approaches presented here should point ‘the way for further 


investigation. 
6.3. Parting shots 


A detailed development of a packet system verification methodology 
based on the ideas presented in the preceding séction is not an easy task, but 
there is a far more difficult problem to ‘be considered. The complexity of the 
systems that are studied will always be a constraining factor for formal 
specification and verification, since formal descriptions grow in complexity 
faster than the systems they describe. The use of the acyclic system — 
characterization theorem and similar techniques can help reduce the 
complexity inherent in many systems, but this reduction will not make 
complicated systems simple. Proofs for systems significantly larger than the 
ones we have discussed may be unmanageably difficult in practice to 
construct in their entirety. Thus, any specification methodology whose only 
goals deal with formal proofs will have limited practical application to real 
systems. No system designer is going to slosh through all the intricate details 
of a proof for a system that he already "knows" is correct. Moreover, proofs 
can contain errors just as much as programs or system designs. However, our 
scheme ivr packet system specifications supports the hierarchical factoring of 
systems into components that approximate the ‘designer's conceptual view. 
Execution sequences ana. packet streams in our specification model are useful 
tools that may be manipulated by a system designer to test out and to gain 


further insight into the operation of packet systems being designed. In this 
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way, ‘we feel that the Seacerts that nave, _— severe" in our research can 


be applied to aid significantly in ‘the Process of designing, using and 


understanding packet systems. 


In summary, the tesearch here has opened up a new area of formal 
specification and verification of computing systems, "Both hardware and 
software. The originality of this work is particularly evident in the context 
of hardware system design. The approaches and techniques that. have deen 
developed here are useful in thelr own right and.alsp help. point the way for 
future work in understanding and verifying systems, 
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